I have created an application which uses a SQL Express database. The program runs fine on the the computer where I built the app, however when I install the app on another computer I get an error telling me that under default SQL Express does not allow remote connections. The problem is that I dont want a remote connection I want a local connection, the database file is on the commputer. How can do get my application to look for the database on the local machine.
My connection string is:
Data Source=(local)\SQLEXPRESS;Initial Catalog="C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\PLDAQ.MDF";Integrated Security=True
I have made sure that the file is in the correct directory.
Any help would be greatly appretiated
hi,
the folder you are referencing is not a "standard" one in the "traditional" sense of SQL Server, and you can get problems if the account running the instance is not able to access that path... and anyway you should reference the intital catalog in the connection string via the "logical" name and not the physical primary data file name, thus
Data Source=(local)\SQLEXPRESS;Initial Catalog=dbLogicalFileName;Integrated Security=True
or use the AttachDBFilename feature of the User Instances mode..
try modifying the connection string to see if you are granted connection to the instance you are dealing with, as the exception you are reporting is quite a generic connection exception..
regards
|||Andrea
I still have the same problem, I have updated my connection string to this:
Data Source = .\SQLEXPRESS;AttachDBFilename = [DataDirectory]\PLDaq.mdf;Integrated Security = True; UserInstance = False
I have managed to get arround the error by changeing the name of the non-design computer to mach the name of the design computer, this however, as I am sure you will agree, is only temporary as I don't want to have to change the name of every computer that I install this application on, what do I need to do to rectify this situation.
|||hi,
as you are not using "User Instances", I'd not go for the AttachDBFileName property of the connection string.. I'd attach/create the database once and then I'd go for the "traditional" Database=yourDbName property of the connection string...
I have managed to get arround the error by changeing the name of the non-design computer to mach the name of the design computer
do you mean by that you "named" the destination computer the same as your dev pc? this is obviously not "mandatory"...
what is your |DataDirectory| value?
regards
|||
do you mean by that you "named" the destination computer the same as your dev pc? this is obviously not "mandatory"...
Unfortunatly this is the only way it will not generate the error posted above. Like I said the program is looking for a remote connection but I want a local one. So I tricked it into thinking that it was running on the dev computer by changeing the name. I will agree that this is obviously not convient, but that is why I am posting I just cant figure out how to fix it.
The |DataDirectory| tells the connection to look in the bin\debug folder during dev time, and also to look into the bin\data folder at run time, after installation obviously. So when the program is installed and all data files are stored in the (AppPath)\bin\data directory and that is where the program is supposed to look for the data files (e.g. Database and Log files), however, if the non dev computer has a different name it trys to find the dev computer to connect to the database, a remote connection, It cant do this as it is not connected to any network.
I have tryed the traditional Database = yourDbName and that causes the same problem
Also There may come a time when I want to use User Instances, but for the time being I just want the thing to work.
|||PEng1 wrote:
Unfortunatly this is the only way it will not generate the error posted above. Like I said the program is looking for a remote connection but I want a local one. So I tricked it into thinking that it was running on the dev computer by changeing the name. I will agree that this is obviously not convient, but that is why I am posting I just cant figure out how to fix it.
the fix is using
Data Source = .\SQLEXPRESS or Data Source = (Local)\SQLEXPRESS property in the connection string...
here you have to specify the instance you have to connect to, and you can provide "." and/or "(Local)" for "local" connections"...
The |DataDirectory| tells the connection to look in the bin\debug folder during dev time, and also to look into the bin\data folder at run time, after installation obviously. So when the program is installed and all data files are stored in the (AppPath)\bin\data directory and that is where the program is supposed to look for the data files (e.g. Database and Log files), however, if the non dev computer has a different name it trys to find the dev computer to connect to the database, a remote connection, It cant do this as it is not connected to any network.
pay attention to your "custom data folder"... consider that the account running the SQLExpress intstance required adeguate NTFS permissions to that folder.. and consider Vista "headaches"/requirements with regard writing in Program Files folder...
regards
|||Andrea,
I guess that I had the answer for a while and just didn't bother to check if it would work with a different name, or I changed something and just don't remeber what, probably the latter of the two, either way, the problem is resolved and I am greatly indebted for all of your help. Thanks a lot.
This program will be run on Windows 2000 for quite a while but it will eventually have to be moved to Vista or higher, what "headaches" are you refering to, I am not at all familiar with Vista since the company I work for still has some machines that are running 95 and One that is running DOS, yeah thats right I said DOS. I guess however that I should probably read up on the New OS any recomended reading?
|||hi,
Andrea,
I guess that I had the answer for a while and just didn't bother to check if it would work with a different name, or I changed something and just don't remeber what, probably the latter of the two, either way, the problem is resolved and I am greatly indebted for all of your help. Thanks a lot.
This program will be run on Windows 2000 for quite a while but it will eventually have to be moved to Vista or higher, what "headaches" are you refering to, I am not at all familiar with Vista since the company I work for still has some machines that are running 95 and One that is running DOS, yeah thats right I said DOS. I guess however that I should probably read up on the New OS any recomended reading?
start reading at http://technet.microsoft.com/en-us/windowsvista/aa905108.aspx, http://technet.microsoft.com/en-us/windowsvista/aa906021.aspx, ....
and look in this forum for Vista troubles with UAC..
regards
No comments:
Post a Comment