Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Troubleshooting server connection
Message
 
 
To
04/04/2012 18:56:52
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Microsoft SQL Server
Category:
Other
Environment versions
SQL Server:
SQL Server 2005
Miscellaneous
Thread ID:
01540265
Message ID:
01540376
Views:
26
>>This is more information on the problem with VFP 9 application not being able to connect to the SQL Server database.
>>
>>After some testing the customer reported that they indeed can connect this application to the server from some computers but not from 2 PCs. Actually these two PCs are the primary users of the application and until today didn't have any problems. But they (the customers) are doing many changes on their network (I believe).
>>All PC, the ones that can and cannot connect are Win XP (so the UAC of Windows 7 does not apply).
>>
>>This SQL Server is set to use SQL Server Authentication. And the computers that do connect use the same credentials (user id and password) as the ones that cannot connect.
>>
>>What else can we look at on these two PCs that cannot connect? TIA.
>
>Maybe they aren't on the same network anymore - I've had such a case where two parts of the house ran on separate networks, and the server had two network cards to connect to each. So I had to have two connect strings. May not be the case, but is worth checking.
>
>Maybe the server is upgraded to a newer version, and these two machines don't have the new ODBC client installed.
>
>Maybe the other machines log in to one domain and these two into another, and the users for this domain aren't included among those with rights to connect.
>
>A simple way to check all this would be to have the tech guys try to create a file DSN on these two machines - then look at the .dsn files and actually send those to you. The .dsn file is actually a connectstring with semicolons replaced with chr(13)s, plus a header in brackets such as section header in an .ini file. If they are able to create those (using SQL authentication!), then you can compare with your connectstring and see what's different. If they can't, let them investigate why they can't. Just make sure they create the file DSNs, not the other two kinds, because those are stored somewhere (in odbc ini or registry, I think) and you can't rely on these guys to be able to extract them and send them to you.

Thank you very much. This sounds like a good approach. I will call them tomorrow.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
Previous
Reply
Map
View

Click here to load this message in the networking platform