Unanswered: Looking for SQL-Server ODBC parameters
I've been browsing all over the net, through technet and MSDN as well, all to no avail.
I'm looking for the parameters I can use with SQL-Server drivers of MDAC 2.7 when using dbcconfig in scripts.
E.g. with mysql you can do a line "DSN=Test;Description=Test Odbc DSN;Server=Test_server;user=stars"
Using odbcconf configsysdsn "SQL Server" "DSN=Test DSN;Description=For stars;User=Stars" I get the error "Unable to create a data source name for the "sql-server" driver, drivers configdsn, config driver or configtranslator failed.
If i remove everything but the DSN name, it works, so I must be getting the parameters wrong. But exactly where, I'm not sure..
First of all, you should consider to use the native SQL Server OLE DB provider, instead of the ODBC provider. Microsoft declared this provider already obsolete.
Secondly, you reporting two different things: Your MySQL line specifies the ConnectionString as required for the ODBC OLE DB provider. Your SQL Server line, however, does the same, but you are trying to mix that with ODBCConfig.
So, I'm not sure what you want to achieve:
1) specify a DSN-based connection string
2) dynamically define a DSN
3) specify a DSN-less connection string
The old ODBC providor is merely contained to an older system not yet phased out. Based on a SQL-Server 6.5. As all programming ressources on that system has died out, its merely a question of time before an entirely different system is set in place.
My problem (literally) is to keep the system alive as is, and in this case it is to define a DSN through loginscripts using ODBCconfig, as I would otherwise have to churn around with 150 machines creating a host of different DSN's.
In my testing case I am able to give a MySQL DSN more specific arguments using ODBCconfig as opposed to the SQL-Server DSN. Namely which user the DSN should use, and what DB to access... and I can't see the sense in that, as I need to specify user and DB as you would normally do using your ODBC administrating tool.
That would require a recoding of this ancient Access 95/97 and SQL 6.5 based system, which is practically like sticking your hand into a wasp-nest. Or do I read the stuff wrong?
Its the database front-end that needs the system DSN's, and in the database there are hordes of linked tables, queries and code all built up against the presence of the system DSN's.
Recoding of the app is pretty much out of the question, as it is destined to be replaced within 6 - 12 months.. so I just need a way to distribute the system DSN to our workstations, in which case I chose odbcconf as it could be called from the login-script.