I am having a strange problem with my WPF desktop application that it cant find a shared folder on a server on the local network.
This problem occurs on 2 machines that I have encountered to date.
The path is to a shared folder as I say on a local server pointing to a folder which contains Visual FoxPro database files ( dbf files )
Within my program I get the value of the path from my app.config file.
I then use the path to set up an OLDEB connection to read the data in a dbf file ( visual foxpro table )
I have the path stored as an appsetting in the app config in the following format : \SERVERNAME\sharedFolder
Within my code I retrieve the path value into a variable 'path' and use that value as so : #path
I have also installed the Microsoft Visual FoxPro OLE DB Provider driver.
I installed my program on several windows 7 machines. All of which are part of a workgroup and not a domain. 2 machines out of 5 produce the following exception message " Invalid path or file name. "
UAC settings are the same on all machines also.
On the machines that the error occurs, I can access the shared folder by entering the path ' \SERVERNAME\sharedFolder' in the address bar .. so, the folder is definitely accessible.
I am not sure what else to check if all machines ( as far as I can see ) are set up the same.
Any help would be appreciated.
many thanks in advance
Something to test on a client where it doesn't work is replace the SERVERNAME with the IP address. It could be a DNS resolution issue. (ran into my share of those.)
If it still cannot access that server then I would assume the issue is security. check the users security permissions. If you can get them to log into your dev pc and try running the code so you can see the issue. If not make a test app that just accesses that location and variants such as just \SERVERNAME etc and see what it does. Test read and then write separately.
Obviously check manually that the server can be read from / written to from that PC.
Related
I've been stuck on this for sometime now. I have an SSIS package thats supposed to read a file and populate a database. I need to run it from a SQL Server Agent Job and the source files to read are located on a folder in another server that I have shared with this server.
The shared path to the folder looks like like this: \\server\D\folder\folder
However when I run agent job through a service account it tells me File name property is not valid. Filename is a device or contains invalid characters
The SQL Server Agent uses a service account to run this job. It runs just fine if the source path is located somewhere on the machine where the database instance lives, however I can't get it to run from a shared folder. If I run it myself by right clicking on the SSIS catalog I can run it just fine. I am aware that it is most likely a credentials issue, but all of these servers and accounts were not set up by me. Can someone help me explain how I should go about adding appropriate permissions to the said SA account so it can read the files successfully? Some examples/references would be greatly appreciated!
Things I've tried: Going to the folder security tab and adding all permissions to everyone on both the server where the folder originally is from and the server that the folder is being shared from. I can confirm everyone has the permissions with the windows PowerShell Get-Acl command.
Switching owner of the job task in SQL Server Agent to my account (I don't think its supposed to work ever to begin with) - this makes Agent complain about being "Unable to determine if user has server acces" with SA account it does have server access, it just can't read the folder.
I saw a post where someone suggests to change the SQL Agent Job advanced step option to "execute as user" and change the user with appropriate credentials, but I don't even see that option in my MSSQL.
I have stumbled upon this thread here , it was never really solved it seems but it looks like the 3 steps given should help me:
Assume that we need to write \serv\share\dir1..\dirN\targetDir\somefile.txt using SSIS throught SQL Agent Job and nonadmin proxy account MyDomain\TestAccount
MyDomain\TestAccount need read/write access to share \serv\share
MyDomain\TestAccount needed at least FILE_READ_DATA permission for all folders (share,dir1,..dirN)
MyDomain\TestAccount needed the CHANGE rights + FILE_DELETE_CHILD permission for folder targetDir
However, me being new to this, I have no idea how to properly check whether or not all these 3 conditions are true and if they are even completely relevant to the problem
EDIT:
There is a project-level variable in SSIS that determines where to read from (in this case set to \\server\d\folder\folder)
This variable is passed into forEach file enumerator in a for loop.
There is also a fileName variable used to check if file name was already loaded in the db as I store them in the table. The variable goes like this:
DECLARE #FileName VARCHAR(50) SET #FileName='' IF EXISTS (SELECT 1 FROM FileLoadStatus WHERE fileName = #FileName) BEGIN SELECT 1 AS FileExistsFlg END ELSE BEGIN SELECT 0 as FileExistsFlg END
If variables are at fault, I still don't know why it works if I execute it manually through catalog myself, but SQL Server Agent is unable to execute it through an SA account
EDIT 2: Exact errors say the following:
EDIT 3: Now that I have set a windows system task to execute the SSIS package instead of a SQL Server Agent Job it just tells me that the "for each file enumerator is empty" basically meaning it can't find any files in the destination to read, even though files are there
it might be a late respond, for all who come to check for an answer to this issue:
the main thing is to be sure that the SQL agent has the authority to read from the shared folder:
1- hold down the Windows key and press R on your keyboard to open the Run command in windows.
2- type services.
3- search for SQL Server Agent.
4- as in the screenshot shows on the logon option you will find which user the agent is using, be sure that this user has the authority to read from the shared folder.
or change the user to another one with the right credentials.
5- you can check the users of the shared folder by right clicking on it and choosing properties --> security. From this window you can change the credentials of the users.
I have written a VB.Net application that uses an SQL Express DB file containing a single table and a handful of stored procedures.
I have successfully built and exported the application to my VPS.
The problem comes when knowing what to do concerning the database file, there is a wealth of stuff online but not specifically to suit my needs.
I plan to use LocalDB on the VPS but being commandline - it is hard to know if the scripts that I have run have been successful after creating an instance , starting it... etc,
I want to keep installation requirements to an absolute minimum on my VPS machine and (in time other end users machines)... hence using LocalDB and not SQL Express
So, what do I have to do on the VPS to enable my application to connect to the database.. ? This was simple when it was Access - (supply the MDB file and run the AccessDatabaseEngine(redistributable) - job done)
The connection on my devt. machine runs as expected.
The connection string in my code is:
Const strSQLConnection As String = "Data Source= (localdb)\v11.0;Database=SoccerTrader;Trusted_Connection=True"
Can anyone help please.. this is driving me around the bend.. surely it cant be that difficult..?
===========================
I have found the following in an MSDN blog which says:
Database as a File: LocalDB connection strings support AttachDbFileName property that allows attaching a database file during the connection process. This lets developers work directly with databases instead of the database server. Assuming a database file (*.MDF file with the corresponding *.LDF file) is stored at “C:\MyData\Database1.mdf” the developer can start working with it by simply using the following connection string: “Data Source=(localdb)\v11.0;Integrated Security=true;AttachDbFileName=C:\MyData\Database1.mdf”.
================ ADDED 12th June =====================
OK, this is really bugging me now... I have read around this till it is coming out of my ears and nothing specifically seems to target what I am trying to do. All the blogs I read refer to installing / running SQL Server and changing permissions etc.
As I have mentioned I am using a VPS and propose to use LocalDB on the VPS to access a simple/small database file for a VB.Net application I am writing.
This is the story so far.
1) I have built a working prototype on my development PC and connected using SQL Express to a database file SoccerTrader.mdf - no problem.
In the Visual Studio Project properties I have added a requirement to the project that checks for SQL Server ..and if it is missing, installs it...
2) I install the project on the VPS and as expected SQL Server 2012 LocalDB is installed .... see here..
3) I have copied the SoccerTrader.MDF and SoccerTrader.LDF files into "C:\BESTBETSoftware\SoccerBot" on the VPS
4) for practical reasons given the problems I am having getting this to work, I have implemented an inputbox for me to specify the connection string when the application runs.... the connection strings I have used give the following...
1]: http://i.stack.imgur.com/i2tro.png
I have not changed any file permissions on the development PC and the database state is NOT read only....
So, the question is where do I go from here...? What have I missed.. why is it not working..?
I have managed to sort the problem.
Seemingly, the connection string I was using was OK. It was my error handling that wasnt 'clean' enough. It transpired the connection was being made on my VPS but when the application attempted to update the table , the directory I had created and put the MDF file into, would not permit write access.
I moved the MDF into the C:\Users\Public\Documents folder and all works as it should.
You have to specify the full path of the Db file with folder name/ip-address
I am trying to do single query to a dbf(FoxPro 9) file through
SqlServer, the problem is that this files are located in another domain, so i configured a LinkedServer with a valid remote user and a remote password in the security page of the linked server, and when i try to execute the query i get the error:"Invalid path or file name", but if i open the Windows explorer and go to the location of the dbf files, then i close the explorer and launch again the query, now Works fine, i don't know why, Any idea?
It wouldn't work, if you need to connect using a username and password. If the remote location allows connecting without a username and password then it would work, that is why it works after you manually make the connection. Use a mapped drive as a workaround. OTOH linked server to VFP is not much of a value, I doubt it is worth it.
If authorization is correct it may be a problem with mapped drives. The query is executed on the server so that machine needs to have access. Have you tried windows explorer on the server? Have you tried a UNC path?
I'm attempting to get SQL Server Service Broker working across database instances and an at the stage of copying certificates (from initiator to target and vice versa). I can back up the certificate to a file but once created I can't open the file or copy it to any other location. If I try and open the file I get a message box with the title "Invalid Public Key Security Object File" and the message "Access is denied.".
The server is within the local domain and is running Windows Server 2008 R2 Enterprise with SP1.
This works (but I cannot do anything with the file):
BACKUP CERTIFICATE UserCertificateB TO FILE='C:\Certs\UserCertificateB.cer';
This doesn't work:
BACKUP CERTIFICATE UserCertificateB TO FILE='\\localmachine\Certs\UserCertificateB.cer';
Error message is:
Msg 15240, Level 16, State 1, Line 2
Cannot write into file '\localmachine\Certs\UserCertificateB.cer'. Verify that you have write permissions, that the file path is valid, and that the file does not already exist.
I can back up the certificate to a file but once created I can't open the file or copy it to any other location.
Yes, the access is restricted to the SQL Server service account. Grant permissions as appropriate on the file, using an administrative account. Use icacls.
Cannot write into file '\localmachine\Certs...'
You are doing a 'double hop' so it requires Kerberos constrained delegation. Contact your network administrator to set it up properly for you.
I know this is an old question, but maybe this answer will be relevant to others that may find the same issue.
If it shows the error ‘Msg 15240, Level 16, State 1, Line 8
Cannot write into file 'C:\tmp\cert\MY_TDE_CERT_KEY.PVK'.
Verify that you have write permissions, that the file path is valid, and that the file does not already exist.’
It is because the script has to be executed on the server and not the local computer connected to the server.
Once the SQL script executed in the server then the files will appear in the selected folder in the server (must create a local directory).
Error (the image shows the path of the local computer, it was the wrong path, must be in the server):
After executing in server
Learned this from Microsoft:
"The path is relative to the SQL Server instance. The path needs to be setup on the machine hosting the instance."
I recently deploy one web application in one of my development servers. I'm using oracle, asp.net and c#. When I run the application in the server everything works fine, but when I try to run the application outside of the server (using my pc, for example) i get this error:
ORA-12154: TNS:could not resolve the connect identifier specified
If i run the application in my pc with visual studio it works fine.
Oracle is installed in Server "A" and the application is in server "B". Server "A" is in one domain and server "B" is in other domain.My pc is in the same domain has Server "A".
In my pc I can find the file tnsname.ora in C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN, but in Server "B" i can´t find it anywhere
any idea?
Thanks for the help.
Have you tried this yet? (from http://ora-12154.ora-code.com/)
ORA-12154: TNS:could not resolve the connect identifier specified
Cause: A connection to a database or other service was requested using a connect identifier, and the connect identifier specified could not be resolved into a connect descriptor using one of the naming methods configured. For example, if the type of connect identifier used was a net service name then the net service name could not be found in a naming method repository, or the repository could not be located or reached.
Action:
- If you are using local naming (TNSNAMES.ORA file):
Make sure that "TNSNAMES" is listed as one of the values of the NAMES.DIRECTORY_PATH parameter in the Oracle Net profile (SQLNET.ORA)
Verify that a TNSNAMES.ORA file exists and is in the proper directory and is accessible.
Check that the net service name used as the connect identifier exists in the TNSNAMES.ORA file.
Make sure there are no syntax errors anywhere in the TNSNAMES.ORA file. Look for unmatched parentheses or stray characters. Errors in a TNSNAMES.ORA file may make it unusable.
If you are using directory naming:
Verify that "LDAP" is listed as one of the values of the NAMES.DIRETORY_PATH parameter in the Oracle Net profile (SQLNET.ORA).
Verify that the LDAP directory server is up and that it is accessible.
Verify that the net service name or database name used as the connect identifier is configured in the directory.
Verify that the default context being used is correct by specifying a fully qualified net service name or a full LDAP DN as the connect identifier
If you are using easy connect naming:
Verify that "EZCONNECT" is listed as one of the values of the NAMES.DIRETORY_PATH parameter in the Oracle Net profile (SQLNET.ORA).
Make sure the host, port and service name specified are correct.
Try enclosing the connect identifier in quote marks. See the Oracle Net Services Administrators Guide or the Oracle operating system specific guide for more information on naming.
Resolving TNS errors can be a real pain. A few things to keep in mind.
Most development environments (like visual studio) keep their own copy of the TNS connection information, and do not use the TNSNAMES.ora file. The file where this information is kept does not have to be called TNSNAMES.ora, that's just the default name. Which may be the reason you can't find it on Server B.
If you have the oracle client software (or an oracle database) you can use tnsping to check if your TNSNAMES.ora file is configured correctly.
The most frequent problems with a TNSNAMES.ora file configuration are using the wrong service name and/or using the wrong host name. You may need to change the "ODB_A" to "ODB_A.WORLD" or vice versa, depending upon the SQLNET settings. For Oracle 10, the latter is the default SQLNET setting. For the latter, you need to use ping to see server "A", and know if you need to use "SERVERA" or "SERVERA.DOMIN.COM" or an IP address.
Do not put # in the password you are setting or remove it from the password.
I was also getting the error and after changing it, the error got resolved.
Guess: An oracle client is not installed on Server B.
If you do have an oracle client installed then you can still put a tnsnames file in any location (Such as a directory on a network share). In order to do this, set a TNS_ADMIN system variable (System Properties->Advanced->Environment Variables on XP) to the directory containing your tnsnames files.
For me for example I have a system variable: TNS_ADMIN - C:\oracle\ora92\network\ADMIN
Is ORACLE_HOME set on server B?
It seems you need to install Oracle Client on "Server B" (the application server), and configure it's TNSNAMES.ORA file. This is required since otherwise, the running code will have no idea where to look for the database you use in the application (probably you're configured a data source in web.config or hard-coded something).
Remember - you cannot access Oracle (easily) without Oracle Client.
Had the same problem. Turns out the TNSNAMES.ORA in out deployment environment had a different ADDRESS_NAME and SID/SERVICE_NAME ,and the application was configured to use the SID - which caused the problem.
Your connection string must contain the ADDRESS_NAME and not the SID
Possible Resolutions -
Verify that the TNSNAMES.ORA exists and is accessible.
Make sure that there are no syntax errors in TNSNAMES.ORA.
Verify that the connection string is correct.
Verify if there are any DNS issues.
If the problem is while connect to server using PL sql developer client.try to install SQL developer within Program File instead of Program Files(x86)'s
Add the environment:
Variable Name: TNS_ADMIN
Variable Value: (YourDrive):\app\(UserName)\product\11.2.0\dbhome_1\NETWORK\ADMIN
I had faced the similar issue. The below code was working in my system but was not working in another server even though I had added a tns entry in tnsnames.ora file.
con = new OracleConnection();
con.ConnectionString = "User Id=username;Password=password;Data Source=uit45";
con.Open(); // throws error here
After digging and digging, I found out the solution for this. We need to ignore the entry in tns file and can be given tns entry as connection string, which worked fine for me. Try the below code.
con = new OracleConnection("Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-uit45.xxx)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SID=uit45)));User Id=username;Password=password");
con.Open();
Note that you need to give the associated values, especially for HOST,PORT,SID,User Id and Password.