ADO.NET works fine when it comes to reading tabular data from excel files, but one problem I often run into is that if the excel file is locked by some other user there is an exception when ADO.NET attempts to retrieve the data.
Is it possible to tell ADO.NET to read contents from the excel file even if it's locked? If so, how can it be done? Do I need to add something to the connection string? The extended properties of my connection string are:
Excel 12.0;HDR=YES;IMEX=1
I had similar problem and I could not find a solution. I ended it up with timer re-trying to connect to a file.
The problem lies in the database itself. In the end of the day it is only a flat file and ADO requires exclusive access to it. You probably need to migrate your solution to MS Access mdb file or a proper(ish) database (SQLite?)
Related
I have an Excel workbook that has several External data connections via PowerQuery (actually from built-in Data > Get External Data, and slightly modified code in PowerQuery to include variable filenames). The connections are made to .xslx, .xlsm and .csv files.
As I read, Microsoft states that it is possible to refresh existing connections on Mac, that are made to these types of files (not sure about .xlsm, but probably that does not matter, as not a single connection refreshes). However, when I try to refresh a query, it throws an error:
[Expression.Error] The module named 'ExcelInterop' has been disabled in this context.
At first, I thought it was a connection to Named Table in the current workbook (as I read on Microsoft, it is not supported in Mac), but even when I removed it, the problem persisted. There is not really much information on Google on this issue, so I post it here. Is there a way to actually refresh the data on Mac or no? Thanks to all.
I have an excel front end which connects to a number of data sources. I would like changes made to the data using the front end, to update the source. How do i do this? The connections are to locally stored workbooks. They will eventually move to network stored workbooks which others can modify directly.
Your best bet is probably a connection string. Then use some SQL queries. Although I have not tried it myself. My co-worker does it all the time - update a front-end workbook then then update another workbook automatically by VBA.
Source: https://www.connectionstrings.com/excel/
I'm trying to wrap my head around it. I've checked other questions and nothing seems to be too similar.
The Office 2013 development centre contains extensive DAO examples and states it is one of the easiest ways to work with an Access file (does not require an Access window) but DAO is a deprecated technology. (https://msdn.microsoft.com/en-us/library/office/ff834801.aspx)
I'm trying to write an Excel Add-in (eventual end point) that will grade Access assignments in .accdb format.
I'm can't just use ADODB to perform SQL queries to extract data, unless SQL can also do the following:
check a specified report has a specified title
check that specified tables, queries, forms, and reports exist
check specific fields in a table exist
check that specific fields have been set as the Primary Key
I also need to check that certain values exist in a table, but those I can solve with SQL.
So should I be using DAO or stick with ADODB? Remember, I'm using Excel, not programming in Access VBA.
The simplest way to work with excel tables is to link them in Access either manually or via the TransferSpreadsheet function in VBA. If you use a generic naming standard for the file names and tab names in Excel, you will not have to relink, rather you can replace the Excel file and the Access link will read the new file unless the layout has changed.
Once linked you can use the query-by-example tool to write your queries which also can be written into code (i.e. either embedded in the VBA [old school and not a best practice] or saved in an Access table then looked up and assigned to a variable for use with the CurrentDb.Execute strSQL, dbFailOnError command.
I suggest manually linking the first go round so you can manually define the individual column types vs. letting Access mess it up.
If you cannot use generic names and have to pick the file via a browse dialog, you can get a file browse function via Google to allow you to programatically link the file. (or you can rename it to a generic name which works even better)
So DAO vs. ADODB is moot from an Access perspective. I supported 50 databases with 70,000+ lines of code and dozens of Excel source files the past 4 years and never had to ponder the question.
Microsoft originally deprecated DAO in favor of ADO, but recently renamed DAO to Microsoft Access Engine (ACE) and is now pushing it as the preferred data access technology for Automation-supported environments (VBA, WSH etc.)
In general, in your scenario I don't think it makes much of a difference which one you use. I suggest you read through this.
I don't think it's possible to read table/query/field information via SQL. However, this can be done either with the DAO.TableDefs and DAO.QueryDefs collection, or the ADO.OpenSchema method.
RE: forms/reports - I don't know if it's possible to read form/report information via DAO or ADO even without SQL, as it is actually part of the UI objects, and not the data; unless we're talking about reading/parsing the system tables. You may have to open the database in a hidden Access instance and read the forms/reports that way.
HI;
I cannot connect a CSV file to a SpreadSheet when the file is open. Currently a have a csv log file that is being constantly updated. I was able to connect it a an Excel SpreadSheet by normal import from external source with refresh every hour. However, its a big file so I needed to produce the reports using EXCEL SQL. It will not allow me to connect to the file while it is open. It says that the MS Jet database engine cannot open the file'unknown'. It is already opened exclusively by another user or i need permission to view its data. If granting permission is he problem , where do I grant myself permission. On a standard Impor, I have no problems reading the file while it is open, but otherwise, get this message and cannot proce3ed. Any help would be appreciated. If I close the update program, I am able to run the queries, but not if the update is running.
Using MSO 2007 W7 x64
It will not allow me to connect to the file while it is open.
That's right, it won't - there is no way to change this.
You must find another way to solve your problem.
How big is the file? You may be able to make a copy to a temporary filename, and connect Excel to that instead.
It sounds like you are accessing a logfile. LogParser can read CSV. In any case LogParser has an excellent SQL-like syntax and can read CSV files much more quickly and reliably than ODBC. It is also programmable from Excel VBA (or script). Perhaps you can use LogParser to extract the values of interest and then load those into your Excel table instead.
I suspect your best solution will be to use the LogParser MSUtil.LogQuery object from Excel VBA, to extract the values of interest into your spreadsheet. Since I don't know what you are actually doing this is just a guess!
I cannot recommend LogParser highly enough - it is a wonderful tool, and can read just about every standard type of logfile, CSV, TSV, W3C, as well as plain text files and the windows NT event logs:
LogParser 2.2 Download: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en
How can I read an XLS file from VB6? I don't want to use ADO or Automation.
ADO isn't going to work for my particular XLS files, because it guesses the data types of the columns from the data in the first few rows.
Automation is out, because Excel may not be installed on the machine.
I'm hoping for recommendations based on experience - I know how to Google :)
ADO
For IMEX=1 setting HKLM\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel\TypeGuessRows to 0 does miracles. I'm wondering if this can be supplied as a parameter of the connect string.
To make the ADO driver a bit more reliable, you can use add two pieces to your connection string:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\blah.xls;Extended Properties="Excel 8.0;HDR=YES;IMEX=1;MAXSCANROWS=12"
That will force the driver to scan 12 rows before making a decision on data types.