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.
Related
ALL,
Is there a query which will give me the version of the mdb/accdb file created?
Or this info is not stored anywhere?
Background:
I'm working on C++ program, connecting with ODBC driver and want to know ACCESS version behind this file.
TIA!!
Short answer: No
It has been requested from many to have an option to check if a database file supports, say, BigInt or DateTime2 but, currently, you are left with trial-n-error.
However, if you don't plan to modify the scheme, your only concern should be, if the database file is of the old mdb (JET) form or the newer (introduced 14 years ago) accdb (ACE) format.
You can easily obtain that information using DAO, the Database.Version property.
In vbscript, that'd look like this:
Dim dbe
Set dbe = CreateObject("DAO.DbEngine")
Dim db
Set db = dbe.OpenDatabase("C:\Path\To\Db.accdb")
WScript.Echo db.Version 'E.g. 14.0 for Office 2010
Using COM is a lot more verbose in C++ so I'll leave that to you, but the approach could be the same.
Using only ODBC, I'm not sure how to obtain this information, though.
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.
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…
First off, I have very little Crystal Reports experience, so apologies in advance if this is a stupid question. I had this "fantastic" work project dumped on me when a co-worker left, so I'm hoping someone can help as most of the Business Objects links I find that might have solutions just redirect to a generic SAP splash page.
So I have a few hundred Crystal Reports (mostly File Schema 10.2, although some are 8.5 or 12.0) that are stored on a server. All of them have an associated VBScript file that calls them in the following way:
Set AppCrystal = WScript.CreateObject("CrystalRuntime.Application.10")
Set CrystalReport = AppCrystal.OpenReport("<file path to report>")
Set CrystalOptions = CrystalReport.exportOptions
CrystalOptions.DestinationType = 1
CrystalOptions.FormatType = 36
CrystalOptions.DiskFileName = "<file path to output excel file>"
CrystalReport.Export False
According to BO, this should be correct. See the following links about the CR API:
http://devlibrary.businessobjects.com/businessobjectsxi/en/en/RDC_SDK/rdc_com_dg_doc/doc/rdcsdk_com_doc/RDC_ObjectModel62.html
http://devlibrary.businessobjects.com/businessobjectsxi/en/en/RDC_SDK/rdc_com_dg_doc/doc/rdcsdk_com_doc/RDC_ObjectModel151.html#1387900
http://devlibrary.businessobjects.com/businessobjectsxi/en/en/RDC_SDK/rdc_com_dg_doc/doc/rdcsdk_com_doc/RDC_ObjectModel8.html#1646326
So basically the script just executes the report and outputs it to an Excel file. This works great on the old server, but when I try to execute this script on the new server I get the following error:
I assume this is because there's some kind of runtime components I need to install, but I can't for the life of me figure out what. I found this page: https://wiki.sdn.sap.com/wiki/pages/viewpage.action?pageId=56787567
But none of the files I've tried to download have worked, and, frankly, I've found SAPs documentation to be sub-par in this area. I do have Crystal Reports 2008 available, so if I need to update the vbscript to use CrystalRuntime.Application.12 or something and then install the newest runtime files for Crystal Reports 2008 on the server, that'd be fine. But I still need to know what runtime files to use? Nothing I can find has worked. Help?
Apparently this type of call to a Crystal report uses the RDC Report Engine, unfortunately CR 10 is no longer available. You can still get CR XI R2 which still deployed the RDC and it's version 11.5.
There is no RDC in CR 2008, it was actually deprecated in CR 9 and now no longer shipped.
Only other option you have is to convert your app to use Visual Studio .NET and use one of the current CR 2008 or CR for VS 2010 components and rewrite your app to .NET Framework.
No more VB Scripting supported, but that was just the Dev Language...
I ended up just upgrading to CR 2008, and using .NET console projects to replace the VB scripts.
I'd like to force SQL Management Studio - Import Data - from XLS excel file to read one column as specific data type? It does a type guessing. My first N rows contain decimal data, but some later columns have also characters in there. I know I need to specify IMEX=1 in the connection string to the XLS file, but as far as I know this could be done only if I were using ADO.NET application to do it. (this forces Jet engine to honor registry setting HKML\Software\Microsoft\Jet\4.0\Engines\Excel\ImportMixedTypes which is set to Text).
It could also be done if I had developer/enterprise edition of sql server 2008, and editing DTS package to include the connection string. But I use Express edition that does not allow saving DTS packages - what are my other options? Thanks
Use the OLE DB Provier for Access Database Engine (or Jet depending on version of Excel), click the 'Properties' button to bring up the 'Data Link Properties' dialog, click the 'All' tab and in the list edit the 'Extended Properties' item to add IMEX=1.
Where to get the OLE DB provider? The version for the Access Database Engine, known as ACE, which was released as part of Access2007, can be used to open Jet 4.0 data sources including Excel spreadsheets. It can be downloaded from MSDN as 2007 Office System Driver: Data Connectivity Components. The stated supported operating systems are: Windows 7, Windows Vista, Windows Server 2008, Windows Server 2003 and Windows XP. There could be an equivalent for Access2010 but I'm out of the loop.
Add a first row having text data that you remove from the target table after importing the data.