on 2021 Apr 16 3:09 PM
Is there a way to specify a value for ODBC connection parameter "InitString" within a SQL Anywhere ODBC DataSource, or even better, within a SQL Anywhere Connection string. The following would be ideal, but does not work:
DSN=mydsn;InitString=''set temporary option bell='off';''
InitString is described here.
Thanks.
The quotes and semicolons are likely throwing off the connection string parsing. Try
"dsn=mydsn;InitString=set temporary option prefetch='off'"
Something similar worked for me with a 17.0.10 ODBC driver. I could see the set option going to the server and was executed successfully.
Kind regards, Ian
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Ian. This helped me out. I wanted to use the "InitString" capability to authenticate an application from a C# Web API to an OEM SQL Anywhere database via property "connection_authentication".
For the record, the C# required quote escaping as follows:
string connectionString = "...;InitString=\\"SET TEMPORARY OPTION CONNECTION_AUTHENTICATION='...'\\"";
Note that I was not successful at providing a value for InitString in a shortcut to run ISQL such as:
"%sqlany17%\\Bin64\\dbisqlc.exe" -c "dsn=testdsn;InitString=set temporary option prefetch='off'"
I tried several ways to include "set ... 'off'" within various types of escaped quotes with no success. It's not a big deal, because I could do what I really needed to, but I am interested to know why I could not specify InitString in the shortcut.
initString doesn't work with dbisqlc because dbisqlc uses DBLib, and DBLib doesn't support initString.
Kind regards, Ian
I think there is a need for InitString in this case because when I open a connection within my C# Web API, I don't know whether the connection came from the Pool or was newly created. I need to SET TEMPORARY OPTION in the latter case but not the former. In my legacy windows client application, I have for years done the SET TEMPORARY OPTION after connecting, just as you (Chris) suggest.
Thanks, Volker. Please bear in mind that the InitString SQL command in question authenticates the client application to the authenticated database server. Encoding this authentication in a login procedure would make a database authenticated on its own, and thus usable from any application. This circumvents the purpose of authentication.
Well, you had also used the sample with "set temporary option prefetch", and for options like that, a login procedure might be very usable. But even for authentication, you could add logic to the login procedure so only the according app (say, identified via AppInfo connection information) would supply that value - but I certainly agree this would be quite easy to lever out...:)
User | Count |
---|---|
67 | |
10 | |
10 | |
10 | |
10 | |
8 | |
8 | |
7 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.