As announced in this (pseudo-)answer, I have some trouble when connecting to SA 12 datases when not all necessary connection info is given.
I'm using 220.127.116.1101 on Windows XP on both according boxes.
I commonly use dbisqlc/dbisql with shortcuts and connection strings. When connecting as DBA, I generally omit the PWD in the string - for obvious reasons. Say, I use something like
to connect to a running database on another box.
With V11 and all older versions I'm aware of, the connection dialog issues an according error (SQLCODE -103, i.e. "You supplied an invalid user ID or an incorrect password"). You then enter the PWD, the other connection parameters are still there, and all is fine. (Yes, I would then use ENG= and LINKS=TCPIP instead of HOST=, obviously.)
With V12 dbisqlc, in this case the same error message comes up, but unfortunately the according connection dialog is set to the "connect with a running database on the same machine" action (poorly translated...). That's a bad choice as the HOST parameter obviously pointed to a different box. Conesequently, when entering the PWD, the HOST= connection info is lost, and therefore the connection won't succeed, leading to a SQLCODE -100 "Database server not found" error.
So, I have to change the correct action type and re-enter the HOST or SERVER name, and only then the connection will succeed.
With V12 DBISQL, the same connection string does not trigger an immediate error message but displays the "connect with UltraLite database" dialog (though I have never used UltraLite at all!). That's even worse, as this won't lead to any connection success. And when changing the dialog to a SQL Anywhere connect, all connection attributes are emptied, and I have to start from scratch.
And it doesn't seem to matter whether I add "Server=MyServer" to the connection string or replace "HOST=MyOtherServer" with "Links=TCPIP" - dbisqlc still assumes a local connection, and DBISQL still assumes an UltraLite connect. Only by adding "Links=TCPIP(HOST=MyOtherServer)" dbisqlc is assured to try a remote connect (but forgets about the given server name). And DBISQL still likes to connect to UltraLite...
With V12 dbisqlc, if I do add the PWD in the connection string, all is fine.
For DBISQL, it still tries to use an UltraLite connect, for whatever reasons. - Is there any connection parameter / DBISQL option to stop that nonsense?
I guess the behaviour for V12 should be optimized in a way similar to the previous versions's behaviour.
The problem with dbisqlc is likely that it does not recognize the HOST connection parameter, since it was added with v12 and no new features have been added to dbisqlc in several major releases now. The dblib library that dbisqlc uses does recognize it so it works, but if dbisqlc itself has to do any manipulation of the connection string, or display the connection dialog, the HOST parameter will likely get removed.
If the PWD is in the connection string, dbisqlc can just pass it on to dblib and the connection will work. But if there is no PWD, dbisqlc will attempt to prompt for one and then recreate the connection string, As described above, you end up losing the HOST parameter.
I've never seen the dbisql behaviour you mention (using UltraLite by default) so I can't help there.
Update: The dbisqlc problem has been fixed and the fix will appear in 18.104.22.16826. It also affected other ODBC applications that used the connection dialog.
Addition: CR number (according to Karim): 652752. Description:
That being said, Volker is not sure if this fixes the whole problem...
I will leave it up to others to provide an answer regarding dbisqlc, but for dbisql, I believe you might be able to resolve the problem by doing the following:
Once you do the above, DBISQL should remember that you want to connect to SQL Anywhere rather than UltraLite.
------- EDIT ------
I have head back from the DBISQL group. The bad behaviour that you are seeing with DBISQL has been identified in-house and will be fixed in a future release.