I have an SSIS package that is supposed to load files from excel into SQL Server.
Process goes smoothly when excel workbook is not password protected. But when I password protects this workbook, I starts getting error External table is not in the expected format. Any solution that can be done within SSIS to enable SSIS to read this.
The almighty internet search engines suggest it cannot be done:
http://msdn.microsoft.com/en-us/library/ms139836.aspx
Note
You cannot connect to a password-protected Excel file.
However you could create a little tool in another language (powershell is suggested) that will be able to open the excels for you with the passwords (that you have to provide this tool) and save a version of the workbook without password for your SSIS to use.
Alternatively: Dont password protect the excels you use for your SSIS. For protection you might consider setting up a location with limited/restricted/no access for all users but the one that will run the SSIS.
Related
I want to link an excel file to SQL Server 2014 whereby I can edit the file and the data gets updated on the server automatically.
Similar to what happens when you link sql server to Access whereas you can edit the data and the changes take effect in the server.
Thanks in advance
There is no out of the box solution for this. You can do this either of two ways:
Write a C# code which has a file watcher attached to the Excel file which uploads the Excel file using SSIS job to the database.
Create a scheduled SSIS job which imports the Excel file periodically.
Understanding the purpose would allow for greater elaboration.
This depends on the type of data you wish to edit.
For master data, if you have the Enterprise or Business Intelligence edition of SQL Server and Master Data Services set up, there is a plug-in for Excel:
https://msdn.microsoft.com/en-us/library/hh231024(v=sql.120).aspx
For transactional data, I would strongly advise against using Excel as a front-end and would recommend you to consider alternatives.
However, if you are compelled to go down this route, you can achieve this using VBA scripting and linking via a DAL (Data Access Layer) such as ADO.NET. Be aware that giving such power to your users could open up your system to sql injection attacks - only proceed so if you trust the users 100%. Another thing to take into consideration is validation checks - validation checks should be applied to every cell where data can be entered. More information can be found here:
https://support.microsoft.com/en-us/kb/316934
I am running an automated Data job on a windows server that outputs a SAS dataset everyday. On top of this, I have an Excel Report connected via Excel's Local Data Provider.
My problem is, that the Data Connection needs to be manually refreshed by a person with SAS installed on their PC. I have tried writing a piece of SAS code that opens the Excel file on the server and then triggers a piece of VBA that did the refreshing, before closing and saving. This works perfectly if I'm logged into the server. But it doesn't seem to work if nobody's signed in. I believe this has something to do with having an active user session.
UPDATE
The process that I use to connect to a local data source from Excel, looks like this:
Data Connection Wizard
Select SAS Local Data Provider from OLE DB Providers
Add the Route to my SAS Dataset as data source
Select My source table and create a Pivot Report
Is there any way to do something like this?
When you want to run Excel unattended, thus no interactive user is logged on, you can do this with a Windows service. You have to ensure some settings for Excel, as well as it is important how you start excel.
Be aware of Microsoft does not support, or even suggest you to do something like this. Excel is a client software, it is exactly the opposite of a piece of software that is easy to maintain running as as service. Read this excellent article Considerations for server-side Automation of Office about the topic. Even when a little old (talking about Office 2003) it is still state of the art.
Please consider these conditions:
You cannot use the System or Network account, you have to let the windows service running under an account that at least have excel started once. This cannot be done with the named ones (as they cannot be used as interactive users)
Excel has to be opened at least once with the user under with the windows service account will run. You'll have to configure dcom settings, open vba once to initialize it, and most probably set some settings like "trust vba model" to be able to programmatically access Excel
last but not least when starting Excel you have to start it with loading the user profile. The Process.Start method in c# allows exactly that by just setting a boolean value to true.
Doing it like this, Excel should just start fine and update data connection with the VBA.
You may want to implement that windows service in c#, as it is really easy, have a look: Creating a Basic Windows Service in C#.
When using c#, be aware of you have to correctly dispose interop objects, pretty good described in How to properly clean up Excel interop objects
Wanted some opinions on which method is a better practice. We have a sales report that MUST be generated in a very specific format (down to the row colors and fonts).
I already have written a macro which pulls from our database and populates the entire workbook in about 15 seconds. The question is how should it be populated?
1) Process server-side: Users initiate the request on the intranet page. ASP.NET opens the workbook template, executes the macro and serves back the final sheet.
2) Process locally: Users download the blank template, run from their desktops which automatically connect to the database.
I like the first one because I can enforce the template, timing, users, and security of the data. But is running Excel automation on an internet web server recommended? I like the second option, but I'm afraid of losing standardization as template sheets begin floating around the company.
As for server side:
I highly.. HIGHLY.. recommend checking out the OpenOffice/LibreOffice XML format for spread sheets.
You can use the localc binary in headless mode to convert the XML file to XLSX or what have you. I use it to create PDF files instead of using ReportLab.
Alternatively here are some other projects that attempt to write to Microsoft formats directly:
http://pypi.python.org/pypi/xlrd
http://pypi.python.org/pypi/xlwt
As for client side:
If you expect the user to be only using Excel and not any other spreadsheet software then go ahead and use an ODBC data source. ODBC will have to be configured per user unless you use some fun VBScript to pull the data from an HTTP server every time it is loaded. There is also the option of making an XLS spreadsheet that simply holds the data and including it into an XLS document as well which would be both a server and client XLS requirement.
Go for server side. Makes information simple to archive and share and will most likely be multi-platform as well.
If you like to use your first option, then you want to avoid using VBA on an installed instance of Excel on the server. This is extremely resource intensive and does not scale well. Instead, if you are writing ASP.NET code, then you should try using the Microsoft Office Interop functionality that is built into the .NET framework. It should possible to adapt your existing VBA code to run under ASP.NET with some changes, but you will have a much more reliable product in the end.
Example Code
However, as #whardier points out in his response, if this were for a large scale or public site, the suggestions he makes would be much more suitable and would scale much further.
I have a Windows 2003 Server box with Excel 2010 installed, upon which I am unable to create new or execute existing macros in spreadsheets. Note: this machine is in a Windows Domain (and I am not getting much help from the network folks here.)
I can and have edited the macro security levels within Excel (File, Options, Trust Center, Macro Settings --> Enable All Macros) but despite this, when I try to:
Open a spreadsheet with macros, I get an exception "Excel found unreadable content...." which goes on to refer to the VBA macros within the spreadsheet
Create a new macro in a brand new spreadsheet created on this machine, all the toolbar buttons providing access to the VBA editor are disabled.
Could this be a Group Policy setting that allows me to edit the macro security settings, but overrides these settings and prevents me from actually creating, editing, or executing VBA macros? (If so, does anyone happen to know which group policy setting I should be looking for?)
I've run rsop.msc (Resultant Set of Policy) on the machine and looked through every single thing under both Computer Configuration and User Configuration, but I don't see anything related to Excel (or Office) Security/Macros.
In this case, the problem was that Visual Basic for Applications hadn't been installed when Excel itself was installed.
(As usual, Microsoft could do a much better job of alerting the user to this unusual configuration, but what can you do.)
I am trying to render a simple chart using SSRS. The data is in an Excel sheet. I have set up an user DSN and created a data source in SSRS using ODBC.
I am able to query the excel in Data tab. However while trying to preview, I get the following error:
error [hy000] [microsoft] [odbc excel driver] the connection for
viewing your linked Microsoft Excel worksheet was lost.
Anyone knows why this is happening and how this can be solved?
I would consider creating a SQL Sever Integration Services package to import the data from Excel to a SQL database and using the database as the data source for the report. The SSIS package could be scheduled to periodically refresh the data.
Using a file based data source like Excel is vulnerable to people modifying the structure of the spreadsheet and moving, deleting or locking the file.
Seems to be a fleeting error. I deleted the dataset, created a new one and re-ran again. It worked.