March 10, 2011 at 9:22 am
Here are the details... pretty lengthy, so please bear with me.
VB6 application written to use SQLServer (Express).
I have version 2005 installed on my development machine.
When I run the compiled exe on my development machine,
all is great.
So I need to run the exe from (more than 1) network workstation.
The exe is NOT installed on the workstation; the workstation has a shortcut
which runs the exe which is stored on the server/development machine.
To make this happen, I had to make a few "tweaks" to SQLServer, etc..,
but now it DOES work just fine.
I had to make sure that SQLServer Browser is running.
I made sure that TCP/IP was enabled.
I made sure that Port 1433 is open/working.
I had to "tweak" my connection string... it now looks like this:
strProvider = "SQLOLEDB.1"
Set dbdata = New ADODB.Connection
With dbdata
.CommandTimeout = 120
.CursorLocation = adUseClient
.Provider = strProvider
.Properties("Data Source").Value = gl_Servername ‘obtained from .ini file
.Properties("Initial Catalog").Value = gl_dbname ‘obtained from .ini file
.Properties("User ID").Value = "xxxxxxxx"
.Properties("Password").Value = "zzzzzzzzz"
.Open
End With
I have changed the userid and pw to protect my client for this posting.
But rest assured, they ARE correct.
So we have now installed a new server at my client's business.
It has SQLServer 2008 installed.
I have installed my app.
When I run the app on the server, it runs just fine.
But, when I try to run it from a workstation, I get that damned
“80004005…Sql does not exist, or unable to connect” message.
I have made sure that all the SQL settings on the new server are the same as on my development machine.
The userid is identified as a login to SQL on the server.
I am pulling my hair out !!!!!!!
What else could be wrong????
Thanks for any and all help.
March 10, 2011 at 9:34 am
check the firewall. Also from the client machine try a telnet test
telnet <servername> 1433
March 10, 2011 at 9:39 am
I would also check whether the user ID has access to the database you are trying to open. The fact that the ID is defined does not mean much.
March 10, 2011 at 9:58 am
The firewall is not a problem.
I can access the server from another workstation, to view/edit files.
The login ID must be OK, and has access to the database I am trying to get at,
because the program works fine when run at the server.
It only doesn't work when run from a workstation.....
Note that the program resides on the server, and is being executed via a
shortcut on the workstation. Now I know that to actually make this happen,
the program gets shipped to the workstation when the shortcut is clicked on.
The splash screen I have built into the app does show up on the workstation
screen... but then the SQL message appears.
So there must be something between the server and the workstation, which is not
being resolved, whereas when it runs right from the server, this "conflict" does not
arise.
But I can't figure out what.
March 11, 2011 at 11:04 am
You won't believe this... I still don't.
So this workstation has a shortcut to the exe on the server.
Here are the steps I actually took originally.....
Install app on server (SQL is already installed and tables defined, etc., etc.)
Run app on server to verify it works fine.
It does.
Create shortcut on workstation to the app on the server.
Try to run app from workstation.
Error message (as described above).
Ensure all SQL "things" are correct on server.
Try to run app from workstation.
Error message (as described above).
Pull out some hair.
Remove userid from SQL.
Rebuild userid and privileges in SQL.
Run app on server to verify it works fine.
It does.
Try to run app from workstation.
Error message (as described above).
Pull out some more hair.
Install app on workstation (to ensure all DLLs, etc., are available).
Remove exe and ini files from workstation (just to make sure they are NOT on workstation).
Try to run app from workstation.
Error message (as described above).
Pull out more hair.
Copy shortcut info to clipboard.
Delete shortcut from workstation.
Create new shortcut on workstation (paste info from clipboard).
Try to run app from workstation.
It WORKS !!!!!!!
??????????????????????????????????????
Pull out lots more hair.
I HATE these kinds of things.... no understandable logic here at all.
March 11, 2011 at 11:18 am
My deeepest sympathy - I have been through similar situation. (Note my white hair...)
What version of Windows/SP are you running on your workstation?
March 11, 2011 at 3:25 pm
Windows XP on the workstation.
And I have an update.
Today I visited the client site to set it up so that the 7 other workstations
could run the app.
I created a shortcut on the desktop of one workstation,
then tried to run the app...
BANG !!!!!! ERROR message again.
What in hell ??????
So I look at the shortcut.
In the box which says "Target", it says "\\server\folder\app.exe"
In the box which says "Start in", it is blank.
In the shortcut on the workstation which is now working,
in that "Start in" box it has the server\folder of the server where the app is located.
So I put "\\server\folder" into "Start in " that box in the shortcut on the second workstation.
BANG !!!!! Works just fine.
So it seems I need that "Start in" box to point to the server\folder.
I have NEVER seen this be a requirement for a shortcut before.
And I have been working with computers and applications and software since 1968 !!!!
(That's right.... over 40 years).
So I then did the same thing on all the rest of the workstations... all work fine.
Now I know WHAT was wrong... I still don't know WHY.
But I guess that will have to do for now.
March 11, 2011 at 6:18 pm
I am afraid you will have to live with your circumvention. If this happened under Win7, I could report it as a (difficult to recreate) bug. Unfortunately, bug reports for XP are closed.
March 11, 2011 at 7:50 pm
That's all Chinese to me. <g>
March 12, 2011 at 3:38 pm
This sounds like you app is looking in the current folder for it's INI file to get the server and DB name, and not the folder of the EXE. (I think it is called App.Path in VB6.)
So you could either change your app to always look where the EXE is, or make sure that the shortcut always has the correct start in folder.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply