I need to create a procedure to upload data from an MS Excel spreadsheet to SQL server on command. My background is in Access VBA I am attempting to use either of the below Distributed Query methods as described on the Microsoft support website: (https://support.microsoft.com/en-us/help/321686/how-to-import-data-from-excel-to-sql-server). My table name and filename are different, otherwise I am using the exact code below. I receive the error: The OLE DB provider "Microsoft.ACE.OLEDB.4.0 has not been registered." I've tried other OLEDB versions to no avail. Not sure how to check which version of the driver I need. The SQL server that I am working with is 64 bit but my local machines are 32 bit and I think this is causing issues. If anyone can help simplify this issue and point me in the right direction I would much appreciate it. I am well versed in VBA with some SQL background. Other than that I don't have much programming background. Thank you!
SELECT * INTO XLImport3 FROM OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0',
'Data Source=C:\test\xltest.xls;Extended Properties=Excel 8.0')...[Customers$]
SELECT * INTO XLImport4 FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=C:\test\xltest.xls', [Customers$])
The query:
SELECT * INTO [TableName]
FROM OPENDATASOURCE( 'Microsoft.ACE.OLEDB.12.0', 'Excel 12.0 Xml; Database=' + [SpreadsheetFullPath] + ';IMEX=1'' )...[' + [WorksheetName] + '$]'
Notes:
Keep in mind that the query is executed on the SQL server so [SpreadsheetFullPath] is the path on the server and not the local machine.
UNC paths (\\sharedDir\...) are accepted.
Keep Excel worksheets to be imported simple.
When something fails, the errors returned by this driver are very unhelpful, so try to avoid them by observing 3.
You may need to install drivers on the database server: Office 2010, Office 2016
There is a bigmuscled engine called SSIS (Sql Server Importing Services) that does this, with error reporting, transformation of data, scheduling etc. It may already exist on your server. This is not the place to describe it in detail but there are tutorials on youtube. During the years the design environment has either been standalone or a plugin in Visual Studio.
It will sure solve your importing problems, but there is a (steep) learning curve. (Which may pay off in you increased skills!). After SSIS you can continue to SSRS and SSAS but that is another story!
Your current problem is the driver name in the "connection string". It often depends on your server's OS-version. (I.e. what has (not) been installed). Instead of guessing (as I have done, developing on XP and at first deploying blindly on Win7 and Win10), I suggest you ask your Admins to on your server make a ODBC connection DSN file connecting to that Excel file of yours, and then look at the contents of that DSN file. It will contain the connection string and the driver name you are looking for, that suits your server's installation. I have also found that "default port#" may suddenly be required in the string as well when connecting to Sql Server.
Related
I'm having trouble using ODBC to connect from Excel 2016 to a PostgreSQL database.
I tried to follow this answer, without success, and this solution from MS, without any better results...
Has anyone ever succeeded at this? I saw that Excel 2016 had some troubles with ODBC drivers, but that was like a year ago, so I was wondering if things may be better now?
Thank you for your help.
My guess is this is a 32/64 bit thing. It's the single biggest issue we've had with setting people up on PostgreSQL within Excel/Access.
Bottom line: if your Excel instance is 32-bit (which is often the case), then you need to use the 32-bit ODBC driver. The latest Pg ODBC driver has both bundled in the same assembly, so the trick is to go into 32-bit ODBC and set up the driver that way.
From there, it should all be straight-forward:
Data Tab
From Other Data Sources
Microsoft Query
Select the Data source you just set up
And so on.
II am working on a Windows 10, 64-bit version, but turns out my Office package is 32-bit. Once I manually installed the 32-bit postgresql driver here: https://www.postgresql.org/ftp/odbc/versions/msi/, i was then able to correctly enter the Driver along the lines of these guidelines: https://www.connectionstrings.com/postgresql/
Final connection string looked like:
Driver={PostgreSQL ANSI};Server=name.text.ap-southeast-2.rds.amazonaws.com;Port=5432;Database=myDBname;
I had this as a comment before, but another commentor suggested I make this an answer: on excel 2016 for windows, don't waste your time with Data>Get Data >From Database. Instead use Data>Get Data >From Other Sources> From ODBC. To set up the ODBC: Click on the Start Menu. Select Control Panel. Select Administrative Tools and double click the Data Sources (ODBC) icon. Click on the System DSN tab. Here is a more detailed article that I pulled the ODBC set-up text from. Besides being much easier to set up, "From ODBC" comes with Office Business, or Office Home, while "From Database" only comes with Office Pro.
1.Excel 2016, x86
2.You need x86 odbc-driver
https://www.postgresql.org/ftp/odbc/versions/msi/
I used psqlodbc_13_02_0000-x86.zip
3.Create DataSource
-Control Panel
-Administration
-Open the 32 bit ODBC Administrator
-User DSN
-Add new User DSN (MyPostgreDsn), check connection
4.Connect Excel to Postgre
-Data
-From other sources
-OleDb wizard
-Other/Advanced
-Microsoft OLE DB Provider for ODBC drivers
-Connection - use connection string - Build
-Machine Data Source
-Choose created data source (MyPostgreDsn)
-Ok
-Test Connection
-Ok
-Choose table…
The background to my problem is based on distributed computing. I want to have a database with some numbers in them and then a number of computers go through each row calculating another number (a little bit of an over simplification).
The problems I'm having are routed in my poor understanding of SQL servers (I think). I've got Microsoft SQL server 2012 (and 2008) installed on this machine and I've somehow managed to make a server for this task but then the problems arise.
I can't add a table to the server (I'm trying to do this in VS2010). When I expand the server and right click on tables and select add new table i get the following error:
"The server version is not supported. Only servers up to Microsoft SQL Server 2008 are supported."
That stops me making a table and from there I can't move on. I've downloaded and installed the VS2010 SP1 (and re-installed it again when it didn't fix the problem) as I found this suggested for similar issues.
Any help on this would be greatly appreciated. I've read around but nothing seems to work, people suggest using "SQL Management Studio" but I don't seem to have this installed!
Also, I haven't gotten to this step yet, but if this gets fixed any advice/links on how to access the database from a different machine (over the same local network) would be greatly appreciated!
Many thanks,
Fraser
R Harvey gave you the pointer to SSMS - that's the ideal tool to use.
As for other computers accessing your local database - the name of your computer (where MSSQL is installed) is the name of the server in your connection string.
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
I need to develop a service and install it into a w2003 box to read excel files a then process its info. The process is as follows, users will upload excel files using FTP and then my service must take those files, validate and then update a SQL Server DB.
The application runs fine on my computer but on the server it asks for the libraries but when I try to install the MS office 2003 Primary Interop Assemblies, system displays "Please install Microsoft Office 2003 before installing the product".
I'd prefer to stay away of any server upgrade as we should require OKs, etc.. so, is there a simple way to just read excel files without having to install any update in the server.
any comments are welcome.
Thanks,
m0dest0.
ps. using vb.net and vs 2008.
Using Interop on the server is NOT supported by MS - see http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757#kb2
Since Windows Vista MS introduced several security-related measures which prevent a Windows Service from doing "desktop-like" things... which means you would have to circumvent several security measures to get it to work (NOT recommended!).
To deal with Excel in a server-scenario there are several options (free and commercial) out there:
I can recommend Aspose.Cells and Flexcel... didn't try SpreadsheetGear but hear+read lots of good things about it...
Free options (though for the newer xlsx format only!) are for example OpenXML 2 from MS and EPPlus.
For a solution with nothing to install on any recent versions of Windows Server..... I'm not sure the exact VB.NET code, but you should easily be able to do this on any machine using the Microsoft OLEDB drivers that should be available on any recent version of windows server or can be installed from a free download off of the Microsoft website for very old versions of windows server. I'll try to pseudo code this, so you will have to adapt it for VB.NET. Note that in order to reference your fields by name, the first row of the selected area in the worksheet must contain the fieldnames in the column values. Otherwise you will simply have to use numeric values to index each returned field by column position.
Set objExcelConnection = CreateObject("ADODB.Connection")
objExcelConnection.Provider = "Microsoft.Jet.OLEDB.4.0"
objExcelConnection.ConnectionString = "Data Source=d:\path\to\excel\file\on\your\server.xls;Extended Properties=""Excel 8.0;IMEX=1;"";"
objExcelConnection.CursorLocation = 3
objExcelConnection.Open
sSQL = "select * from [worksheetname$]"
set rsWorksheet = objExcelConnection.Execute(sSQL)
do while not rsWorksheet.Eof
sValue = rsWorksheet("FieldName")
rsWorksheet.MoveNext
loop
rsWorksheet.Close
set objExcelConnection = nothing
I use the Excel Data Reader (http://exceldatareader.codeplex.com/) when I need to process Excel files. It handles xls and xlsx files without a hitch, and I've got it running in a few applications on a server OS. It saves each sheet as a DataTable object, and each "cell" in the DataTable corresponds to the Excel cell with the same address. Depending on how you set up your SQL server link, there might not be too much conversion required to dump the contents into the DB.
I have to read two .dbf files that came from a VFP server in SQL and manipulate them. They are sitting in a folder on the server. First, I have installed the VFPOLEDB driver, the ODBC driver, and its update. I have successfully created a linked server to the free tables, and tested it in SQL and it says the connection is fine and there's stuff there. I still can't seem to even look at the files. Anyone see anything wrong with my code? Or any tips? Sample code of known working code? I have found a lot of examples online, but when I apply with the many hours I put into modifying them, they still don't work.
Here is my code:
Select * From OPENQUERY(LINKEDSVR, 'Select * from employee.dbf')
LINKEDSVR parameter info:
Provider: Microsoft OLE DB Provider for ODBC Drivers
Product Name: Microsoft Visual FoxPro Driver
Data source: linkedfoxpro
ODBC linkedfoxpro config:
Datasource name: linkedfoxpro
databasetype: Free Table Directory
Path: c:\somefolder
Driver: Microsoft FoxPro VFP Drver (*.dbf)
Thanks!
Those CDX files are not generated by SQL - that's the index file created/used by VFP. They are very prone to corruption so it is likely that the CDX was already corrupted when you got it or in transit.
By deleting the CDX file, you have removed all indexes from the table and also the source of the error.