I have an SSIS job (2008) which uses variables set up in the SSIS Configurations database table. One of these variables is the folder path which the job should look in for files.
When I have this set to a local path on the same computer it works fine, e.g. d:\Processing\
but if I change this to a network path e.g. \\networklocation\Processing, it fails with the following error
Flat File Connection Manager - Description - the flat file "\\networklocation\processing\" specified in the connection was not valid. End Error. Code 0xC001401D. Failed Validation 0xC001401E
File name property is not valid. The file name is a device or contains invalid characters.
I've read various problems about network paths and SSIS - is there a solution for it?
OK, I made a new Credential on the DB and then a new Proxy and I run the job as that user
That seemed to work ok - must have been permissions that prevented it from seeing the network folder
Related
Hello I am trying to create a new plan on SQL server to backup all my database.
My goal is to backup them to a network drive thus if I do have some trouble with my server, I will be able to restore databases to other server thanks to backup present in the network drive.
When my plan is executed, I do have some error so I try to execute manually the relative query.
After some investigation, it seems even net use command doesn't work (whereas it is working and I do it from cmd)
EXEC XP_CMDSHELL 'net use Z: \\ServerName\loggin/user:loggin password'
error is
System error 1450 has occurred. Insufficient system resources exist to complete the requested service.
Beside, I do have another server where it is working so I suppose some configuration missing but can't find them
as my network drive is also accessible via FTP, I chose this way to make the job : create a batch file that run winscp and use this batch file in a SQL agent job . I need to add right to batch file to SQL Server agent account. I also need to define a credential and a proxy to be used in the job.
I appear to be unable to get my deployed SSIS package to read from a 1997-2003 Excel file.
I get stuck with the following 2 errors:
SSIS Error Code DTS_E_OLEDBERROR, Error code: 0x80004005 An OLE DB
record is available. Source Microsoft JET Database Engine, database
engine cannot open the file, it is already opened exclusively by
another user, or you need permission to view its data.
DTS_E_CANNOTAQUIRECONNECTIONFROMCONNECTIONMANAGER with Error code 0xC0202009
The package itself works with no issues when using SQL data tools on the server logged in as the service account only when deployed to server I see this issue.
To make this issue even more confusing I have setup and tried the following:
Runtime is set to 32 bit on the debugging menu on SQL data tools as well as the job configuration is set to use 32 bit runtime
I am able to UNC to the folder/file when logged in as the SQL service account
Any Ideas?
Thanks,
M
I figured it out in the end. Turns out I missed a step with the permissions.
Yes the Service account had permissions to the folder but I failed to add read permissions to the file itself.
Thanks for all comments/suggestions.
M
I am using following query to load data from text file into database table
bulk insert Test_Training.dbo.test
from 'D:\SSRS\kasthuri.txt'
I have kasthuri.txt file in specified path. But I am getting error when I execute it.
Msg 4861, Level 16, State 1, Line 2
Cannot bulk load because the file "D:\SSRS\kasthuri.txt" could not be opened. Operating system error code 3(The system cannot find the path specified.).
The error message is because the service running your SQL server instance cannot access the file path. Wherever you place the file, you will need to open up the folder where the file resides to the MSSQLSERVER agent:
**I always struggle with this. For me, allowing MSSQLSERVER full permission to the folder where the input file resides always seems to work.*
Right-click the folder (as an admin on the box), go to properties, security, edit, add...
here is where I always get tripped up. For me, the server service account is "NT Service\MSSQLSERVER" and I can never search for that user. I have to type it in manually and check the name to make sure I typed it in correctly. For you, this may not be the service account used by your server. Check your services list from windows administrative tools to see what account is in "Log On As" for SQL Server (MSSQLSERVER).*
I have been scouring the internet for a clear answer to this question and I haven't been able to find one.
We currently have a SQL configuration enabled across packages which stores everything in a database, (dev or prod). It is a tricky process to execute packages, figuring out which configuration the packages are mapped to, and having to change them during testing. My hope is that we can use an environment variable to always use a specific connection string to the specific sql server configuration we want to use based on the machine.
I have seen ways to set up variables with the connection string hard coded as an environment variable with an additional SQL server configuration after to manage this. I have also seen ways to manipulate the connection string using XML and calling that from a variable, or from the package itself.
Both of these solutions work and very well may be viable solutions.
My question that I'm really trying to answer is; Is it possible to develop the entire SQL Server configuration connection through the environment variable? As in combining the connection string with the configuration string so that the one environment variable connects straight to the package configuration? Has anyone tried this? Does it make sense as a solution to the problem?
Yes, we have done this and it works fine. Each package has two configurations: the first is an environment variable and the second is a SQL Server table. The environment variable is the connection string for a database containing a table with all the configurations and it is applied to a connection manager. The SQL Server configuration uses that connection manager to connect to the configuration database and retrieve the individual settings.
Because configurations are applied in order, the connection string for the connection manager is set before the SQL Server configuration tries to use it. In summary:
Create your package
Add a connection manager called "Configuration Database" or whatever
Add a SQL Server configuration to the package, use the "Configuration Database" as the Connection, and choose the settings to be stored in the table
Create an environment variable such as SSIS_PKG_CONF with the connection string to be used for the "Configuration Database" connection manager
Add an environment variable configuration to the package, use the SSIS_PKG_CONF variable, and assign it to the connection string for the "Configuration Database" connection manager
Now when you run the package, the configuration proceeds as follows:
The package processes the environment variable configuration
It assigns the value of the environment variable to the "Configuration Database" connection manager's connection string
The package processes the SQL Server configuration
It uses the "Configuration Database" connection manager to retrieve individual settings from a database table
This has worked well for us because we can change the connection string to point at a different source database for the configuration, without changing anything inside the package or the launcher (i.e. the SQL Agent job or script that runs the packages). There are other ways to do it and some people feel strongly that .dtsConfig files are the better option, but we found it easier to manage environment variables than config files
But in the end managing package configurations is a preference and a lot depends on what is easier in your environment with the tools and practices you already have.
data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true
Specifically what does
AttachDBFilename=|DataDirectory|\aspnetdb.md
mean?
It means that the connection will open aspnetdb.mdb on published app data dir.
This avoid you to read dir inside your web app once published.
Visual Studio does it automatically for you at runtime.
|DataDirectory| (enclosed in pipe symbols) is a substitution string that indicates the path to the database. It eliminates the need to hard-code the full path which leads to several problems as the full path to the database could be serialized in different places. DataDirectory also makes it easy to share a project and also to deploy an application.
For example, instead of having the following connection string:
"Data Source= c:\program files\MyApp\Mydb.sdf"
Using DataDirectory, you can have the following connection string:
“Data Source = |DataDirectory|\Mydb.sdf”
To set the DataDirectory property, call the AppDomain.SetData method. If you do not set the DataDirectory property, the following default rules will be applied to access the database folder:
• For applications that are put in a folder on the user's computer, the database folder uses the application folder.
• For applications that are running under ClickOnce, the database folder uses the specific data folder that is created.
*i forgot to add the link so here ya go ->
http://social.msdn.microsoft.com/Forums/en-US/sqlce/thread/dc31ea59-5718-49b6-9f1f-7039da425296/
*