I just started using SSIS and am trying to upload an Excel file. When I get to the Excel Connection Manager and use the variable pointing to the file path of it's location, I get the following error:
"An OLE DB record is available. Source: "Microsoft JET Database Engine" HRresult: 0x80004005 Description: "The Microsoft Jet database engine cannot open the file". IT is already opened exclusively by another user, or you need permission to view its data."
The SQL Server and SSIS software are brand new. The destination table is already set up. What could I try to fix the issue?
Looks like there is a lock on the file (on the server, right-click my computer, manager, system tools, shared folders, open files).
OR look for Excel Version in Excel connection manager, choose MS excel 97-2003. I assume you are using new version
Make sure you don't have the spreadsheet open in Excel, it will put a lock on the file and prevent it from being opened by SSIS.
sometimes if excel didn't close properly it might leave an instance in memory locking your file. You may need to check it with Task Manager and kill the excel instances manually.
Close out of Server Manager or Visual Studio. It will release the file.
Related
I have an xlsm file with macros that enable data collection from OLE DB source. I just need to make an import package with it in sql server. But when I'm trying to use import/export wizard or ssis-it shows that it can not deal with .xlsm extentions.
Is there any way to deal with it?
follow this :
1-Create an Excel Connection Manager to refer to ANY other spreadsheet with a "valid" XLS or XLSX extension. (You don't have to save your XLSM file "as" an XLSX.)
2-Select the Excel Connection Manager in your Connection Managers pane.
3-Open the Properties Window (F4).
4-Change the "Server Name" property to the full pathname of your XLSM file.
note: check the file should not be in read only mode
Had the same issue (SQL Server 2008 R2), Rahul's solution worked for me, but I just want to add a couple of things:
Select Excel 2007 in Excel version when creating Excel Connection.
Use SQL Command as Data access mode when editing the Excel Source. Visual Studio crashed for me every time I was trying to use Table or view.
I've created a new database using Microsoft SQL Server Management Studio, and now I want to interact with it through LabVIEW. I already have several VIs to interact with a previous database, using the database connectivity tool kit. This database was created by someone who has since left the project and I can't find it in anything but LabVIEW.
I'm quite experienced with LabVIEW, but completely new to and bewildered by databases.
Thank you in advance.
The first Connectivity Toolkit VI called should be Open Connection.
The existing code (VI) will either use a file or a string as an input.
If the input is a string, then you will need to create a new connection string compatible with your server. You can find common SQL Server strings at https://www.connectionstrings.com/sql-server-2008/
If the input is a file name, you can copy the .UDL file that is referenced and then modify the copied file by opening it (double click) and then select the OLE DB Provider for SQL Server and then set the connection options to point to your server, database etc. and then test the connection.
Basically the workflow you have to go through is the following:
Open connection
Execute your query
Fetch data (if needed)
Close connection
If you search for "Database" in the NI Example Finder shipped with Labview you will find a few good starting points.
In particular give a look to Database Connection.vi and Database Fetching.vi.
If you plan to use transactions try also Database Transaction.vi.
I found that the solution to my problem was to create a .udl file and use that as the file path for opening the database connection.
Here's the address that taught me how to do this:
http://msdn.microsoft.com/en-us/library/e38h511e(v=vs.71).aspx
Thank you to everyone who submitted answers, they certainly helped point me in the right direction.
I have among 80 and 100 Fox Pro DBF database files that I want to migrate to MSSQL Server 2012 x64.
Because are too much DBF data bases I'm looking for an automatic/non Manual way of move all data contained in these DBF files to MSSQL Server Data base Tables. One separate table for each DBF File.
I have tried the following code:
SELECT *
FROM OPENROWSET('MSDASQL', 'Driver=Microsoft Visual FoxPro Driver;
SourceDB=F:\SomeDBFPath;
SourceType=DBF',
'SELECT * FROM someDBFFile')
in order to see/explore the data of one DBF, but the following error messages appears:
OLE DB provider "MSDASQL" for linked server "(null)" returns an error.
Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "(null)"
I'm not interesed in use external software like a DBF converter or similar tools.
At this time I have installed the AccessDatabaseEngine_X64 file located at http://www.microsoft.com/en-us/download/details.aspx?id=13255 due to previous recommedations with no success.
Thanks in advance.
Do you have access to Visual FoxPro? If so, you can via the default menu of Tools -> Wizards -> Upsizing.
First, go into Control Panel, Administrative Tools. Under that is ODBC Data Sources (should be a 32-bit version). Go into that and then go to the tab for "System DSN" and click Add button to the right. You will then be prompted to "name" the connection. For grins, something like "UpsizeMyData". It will then prompt you through the connection information to the database you are trying to connect to, user / password for connection, etc. Go through and create the ODBC connection info and make sure the "Test Connection" at the end is successful.
Once this is done, get into VFP. From the menu steps above, it will bring up a dialog window for transferring a database. It will prompt you for the database you want to upsize... pick via a "Get File" dialog. After that, it will prompt you with connection information, the ODBC connection you just created above should be listed. Select that, then "Next". It will then prompt you for the SQL password to start the connection.
Once connected, it will look though your database and look at the tables. You will have a side-by-side picker dialog of all available tables and you can pick those you want to upsize... you can do one, many or all, then click "Next".
The next dialog will show you each of the tables you've chosen and allow you to confirm the data type from the VFP table to the corresponding column data type when pushed up to SQL. You can try by letting the defaults go and try. Click "Next".
Finally it will ask you which database you want to upsize to. You can pick an existing database, OR Add a new (may be your choice for first time to see how things go).
Problem: Could not find installable ISAM
I am executing a query from MS Access in order to pull information from MS SQL Server 2005.
When I attempt to open a linked ODBC connection to the table directly it opens with no issues. However, when I attempt to create a DSN-less connection, I receive an ISAM error.
I have the following error when I attempt to execute my SELECT query:
"Could not find installable ISAM."
The code I'm using is as follows:
SELECT * FROM [Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].[My_View_Name]
The help from MS Access provides the following information:
Could not find installable ISAM. (Error 3170)
The DLL for an installable ISAM file could not be found.
This file is required for linking external tables (other than ODBC or Microsoft
Jet database tables). The locations for all ISAM drivers are
maintained in the Microsoft® Windows® Registry. These entries are
created automatically when you install your application. If you change
the location of these drivers, you need to correct your application
Setup program to reflect this change and make the correct entries in
the Registry.
Possible causes:
+ An entry in the Registry is not valid. For example, this error occurs if you are using a Paradox external database, and the Paradox
entry points to a nonexistent directory or driver. Exit the
application, correct the Windows Registry, and try the operation
again.
+ One of the entries in the Registry points to a network drive and that network is not connected. Make sure the network is available, and
then try the operation again.
I have also found KB articles from Microsoft explaining when and how this should be handled. However they are unclear to me if they are actually rooted from another type of issue.
For example:
283881 and 209805 Tell me the purpose of ISAM is to tell how to format data other then, MS Access' native formatting. (But I don't want to format it in another way and the other formats do not list what I think to be the appropriate format-er)
and, 90111 Tells us the driver in the .ini file may be pointing to the wrong place in MS Access 2.0 which no longer exists in version 97+.
The odd thing is I have a DNS-less setup for another table which works fine. The only difference I see here is the default naming of the database object is not standard, so possibly I am not referring to the schema correctly in my syntax.
What am I doing wrong here? Is it truly a syntax error?*
Are there any "View" permission considerations which need to be made on the server end?
Try adding ODBC; at the start of the connection string and remove the brackets around the view name:
SELECT * FROM [ODBC;Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].My_View_Name
When I try to connect to a database that was previously opening with a SQL connection I get a "File in Use" error. Process Explorer tells me that sqlservr is still holding the file. Any ideas on how to get sql to release the file from within the vb.net 2010 code?
After you closed the connection you must call
SqlConnection.ClearPool
or
SqlConnection.ClearAllPools
in order to release the files from the SqlServer.
Which file is this? Is it a file that's normally internally managed by the SQL server? If so, then you'll probably have to ask the SQL server to shut itself down before you can open the file.
You may also want to consider your reasons for wanting to access such a file. If it's for backup purposes, you are almost always better off using the services of your database to perform backups, instead of trying to do it yourself.