|
Usually, I start dbisqlc with an appropriate connection string. However, when trying to connect interactively, I can only choose among ODBC datasources of the version, i.e. dbisclqc V8 lists only V8 DSNs, dbisqlc V12 lists only V12 DSNs, dbisqlc V11 only V11 DSNs. (As such, it' sno new problem.) In contrast, DBISQL seems to do so by default, too, but has this "search" button to look for different DSNs. Question: Have I met another dbisqlc restriction, or can this by changed by some option? |
|
dbisqlc (actually dbconX.dll) does explicitly filter the DSNs to those that are defined to use the SQL Anywhere ODBC driver of the same major version as dbisqlc and there is no way to get around that behaviour. I can only guess that the filtering was done because we didn't want to show non-SQLAnywhere DSNs. What would you expect -- would you want it to show all DSNs or just SQLAnywhere DSNs? I also found that the 64-bit version of dbisqlc doesn't populate the DSN list at all. Note that dbisqlc is a dblib application and doesn't use ODBC when you use a DSN. The DSN is only used to pick up connection parameters. -john. John, thanks for explaining the behaviour. I guess it is something that has rarely caused problems for me, as I usually use engine and dbisqlc in the same version, and usually use predefined connect strings. I just noticed the behaviour when testing for http://sqlanywhere-forum.sap.com/questions/1240, when I switched between different versions, and noticed that DBISQL let choose me different DSNs. So this is not really a restriction in dbisqlc. - On the other hand, I conclude that DBISQL does extend dbconX.dll to search for different DSNs? 1
dbisql doesn't use dbconX.dll -- it uses its own dialogs implemented in Java. It looks like dbmlsync is the only other thing that uses dbconX.dll. Assuming that team doesn't object to the change, I'll submit a fix for dbconX.dll to list all SQLAnywhere DSN's (at least v6 and up) for dbmlsync and dbisqlc. Otherwise, I'll make a different change for just dbisqlc. @John: That's good to hear (and more than I have expected given the somewhat "deprecated" state of dbisqlc). In my mind, if a change is made, then it would make sense that dbisqlc lists DSNs of those SA versions it can connect to. That will correspond to v6 and up, as you describe. FWIW, according to John this is fixed (with other topics) under CR 645986 cf. http://search.sybase.com/kbx/changerequests?bug_id=645986. |
|
I've had that problem too. If you know the data source name you might overcome that limitation with |
Cf. Breck's comments on http://sqlanywhere-forum.sap.com/questions/1200