0

I'm new to ODBC and DSN's in general.

We have a product A that accesses a database "T" via a DSN D1 that has already been defined.

I'm now writing a test app testA that exercises various functionalities of product A and also needs to validate various database entries made by A.

For this, I am trying to access the same DSN D1 (that was setup for database T) to read from db and do the necessary validations.

I'm however having issues with that. I've setup the dsn, but when I do a SQLConnect with this dsn, I get a return value of -1.(I dont see any corresponding values for this return type either)n

Any clues on what this means and if I'm doing something wrong.Can we have 2 different processes or apps connect to the same DSN?

Omi
  • 976
  • 2
  • 20
  • 35
  • What is the application written in? – Dan Bracuk Mar 16 '13 at 16:20
  • since you DSN D1 is running ok, this should not be related to the DSN itself. Should try to check the code and/or potentially the "rights" of the test app (can the test apps access the DSN D1? --user DSN/system DSN) – jlee88my Mar 16 '13 at 16:39

1 Answers1

0

You can test access using a "udl" file. These files are largly misunderstood IMHO. They are simply a script that is used to launch the (db) connection library. You can create them by creating an empty file in notepad and changing the extension to .udl from .txt. You then double click on the file and configuer access to your database. (they launch a build in configeration applet). In my experience if a .udl file connects then any application will connect or 100% there is a problem with the application. If the udl file will not connect, then 100% there is a firewall or something probibiting access to the account being used to try to connect.

Ian P
  • 1,724
  • 1
  • 10
  • 12
  • Thanks for the response Ian. I tried this and got a success response from this utility. Also, the product can talk to that DSN...so thats probably not the issue. So its probably an issue with the SQLConnect function call itself...not sure what though...since I am passing in appropriate values for the DSN and the HDBC handler...(using Windows auth..so no password or user name) – Omi Mar 18 '13 at 04:14
  • Well if you open the udl file that was created when you configuer it (and it connected) in notepad, then copy and paste to your config settings, you can be sure the string is in all respects correct. – Ian P Mar 19 '13 at 11:14
  • Ok..I could connect (used a char* instead of tchar*..hence the connect error)...however I still get an error while doing SQLExecute(). When I do a SQLGetDiagRec, I get a SQLSTATE = 37000 and msg as "[Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near '0x2073'."...what does this mean? I tried to google it, but couldnt find any relevant answers. The query I'm doing looks something like this: "select Status from [Users_register_db].[dbo].users_tab where Number='user1@xyz.com';" This query looks ok..in fact can run it when I manually type this in the sql window. – Omi Mar 27 '13 at 17:11
  • Well Status is probably a reserved word so you may need to delimit it:SELECT [Status]FROM .... and Number probably is as well WHERE [Number] = 'usr1@xyz.com' but if [Number] is a numberic column type and you are comparing it to a string, then that will fail as well... The usual divide and conquer approach. Try SELECT * FROM [Users_register_db].[dbo].[users_tab] (but if you have selected [Users_register_db] in the connection string) then 'SELECT * FROM [users_tab] should be good. – Ian P Mar 27 '13 at 17:55
  • Just googled SQLSTATE = 3700 and it gave:Detail: Select Error: SQLState = 37000 Microsoft][ODBC SQL Server Driver][SQL Server]Error converting data type varchar to numeric. So I guess its the where statement trying to compare a char string to a numeric column. Ticks and plusses apreciated! – Ian P Mar 27 '13 at 18:02