I recently (today, actually) got some new permissions to some SAP tables, but I'm getting permissions issues with importing them. Here's how my process looks right now:
I have an Access db that links to SAP tables via an ODBC connection.
In that same Access db, a set of spaghetti-like queries pulls & refines a modest data set (a dozen columns, few hundred rows, nothing special). I can run these queries without a problem.
An Excel file imports that data using Data->Import External Data->Import Data. I do this all the time. Except this time, I'm getting the dialog pictured below. Clicking OK doesn't seem to do anything. Clicking Cancel produces an "ODBC Connection Failure" message (or something like that).
Again, these queries can be run from Access just fine. But when I import those query results into Excel, I get this problem. I can get around it with a make-table query, but since someone else is maintaining the Access db, I'd rather not make any changes to it.
I was going thru my old unanswered questions and found this one. I think I solved this by using a staging table in Access to store the data and then later importing into Excel from that staging table.
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 Add-in (with a Userform) which connects to an Access database (using DAO) to perform various functions. I've been using this combo for over a decade. Neither the code in Excel nor the database have been changed recently. Just last week, a user reported that one of their functions was taking much longer than usual, so I looked into it. It ended up that the function itself ran just fine, but when the code was cleaning up and ran db.Close it hung up. It doesn't produce an error, it still eventually succeeds, but it takes around a minute to close the db and move on.
I'll go through all of the symptoms and attempted solutions to see if anyone else has any ideas because I'm at a loss.
This only happens when you run db.Execute. I can open the database and close it right away and it closes just fine. If I open it, run a SELECT query to populate a recordset, then close it, it also closes just fine. But if I open it and run a single UPDATE/SELECT INTO/INSERT/ALTER/DROP statement, the Close method will take a minute to run.
My first thought was to compact the db. I cleared out several unused, old tables and compact/repaired, but this did nothing. Same problem.
My next attempt was to recreate the db. I made a brand new TEST db, imported all of the tables from the old one, pointed my Excel Add-in at the new db and did the same tests. Same results.
My next attempt was to try moving it to a local drive (it's on a network share). This slightly reduced the hang at Close, but it's still there. Not that it matters, because this db has to be hosted on a network share.
My next attempt was to delete a bunch of tables from my TEST database. I cleared out about half of them and the hang at Close was reduced a good deal. Clearing out even more reduced it even more. Deleting all but one table eliminated it. So now I know my problem has to do with the size of the db, but why? It maxed out at 500MB after the compact, which isn't that large. It's been running just fine for years. Why all of a sudden would the size/number of tables be such a huge issue? I obviously can't delete all of the tables in the production database just to solve an issue with Closing the connection.
As I mentioned, this code has been around a long time and the prod db was actually in Access 2000 format (mdb), so my next attempt was to change the format. I tried importing it all into both an Access 2003 format (mdb) and the latest Access 2016 format (accdb). The results were the same.
On a lark, I figured I'd trying hitting the db from somewhere other than the Add-in (on the off chance that the problem was in my Excel file). I copied and pasted my test code into a Word 2016 module... and it ran just fine.
That's odd.
So then I tried a brand new Excel file. Also ran just fine.
So I go back to my Add-in and try the code pasted into a Module.
Again, runs fine.
??
So I open the Userform and run my test code again. Hangs up.
??????
I create a brand new Excel file, make an empty Userform, paste my test code in the form's Initialize event.... hangs up.
I immediately run that same code in a Module afterwards... still hangs up. Even though a minute ago it ran just fine in a module in a different file.
But if I close the file, open a new one, paste in the code WITHOUT opening the Userform, and run it, it works fine. Creating/opening a userform will cause all subsequent attempts to run the code to hang.
So here's the Cliff's Notes version:
Excel 2016 DAO connection to large-ish Access database hangs on db.Close under the following circumstances:
1) The db is large (deleting most of the tables helps but obviously isn't a solution).
2) You have opened any Userform at any time during your Excel session. All attempts during OR after the opening of the form, no matter where the code is run from, will hang. Running the code before opening a Userform does not hang.
These results are duplicated on multiple Windows 7 machines, all with what appear to be the latest updates to Office.
EDIT: I was able to try this out on a remote machine running Excel 2013 and there is no hang (using the original Add-in/db that first exhibited the problem). However, that machine is in our data center which is the same place that the network shares are located, so there are at least two possible reasons why it doesn't hang: 1) Different version of Excel and 2) Different/faster network connection.
If you're wondering why I'm using DAO instead of ADO, it's because of what these functions do (lots of stuff with looping through Tabledefs to modify indexes and even create/modify the table Description, which can't be accessed via ADO. If it weren't for all that, I'd just switch to ADO and be done with it. It's possible that I might be able to come up with ADO alternatives/work-arounds for everything that it's currently doing, but I'd rather not rewrite this entire Add-in if I can help it.
I'm at a complete loss on this one, so if anyone has any ideas, I'm all ears.
I have some queries in my Access database which pull data from Excel files that appear in the database as linked tables. They have worked just fine, until suddenly and inexplicably I was getting the error "External table is not in the expected format," when trying to access them.
I thought it might have to do with the fact that I was using a macro-enabled workbook, but it was fine before. I do have a mail merge set up in Word which is linked to the database, and using one of the aforementioned queries.
It turns out that the issue was due to the mail merge document. Once I saved and closed the mail merge file in Word and tried accessing the queries and tables again in Access, the error was no longer appearing.
It seems that if a Word mail merge is connected to the database, this error may appear. I am not sure as to why a more appropriate error is not appearing; after testing it seems to happen regardless of whether the linked file is a macro-enabled workbook or not.
In short, as Olivier put it, the file was locked by Word. A simple issue, but not exactly clear given the error message (unless you follow Andre's logic that the expected format is a non-locked file, hahah).
I hope this helps someone else!
My form is hooked to a query. The "not in expected format" message happens when the query is set up as a "snapshot". When I changed to "dynaset", the form started to work as expected.
We have an application to track work orders (hundreds of thousands) built on an Oracle database. Data entry is cumbersome and report features non-existent. IT is inflexible. We do not get support from that end. Accordingly, users have created Excel "tools" to run queries and make sense of data using ADO or ODBC connections.
What we also need is a way to record comments on specific work order (WO) records and have those comments travel with those records somehow. There are multiple users using their own spreadsheets, all querying the same database.
I'm envisioning a junction-table approach, perhaps using Access, where some VBA could take a users comment from the row in the worksheet, capture the WO number, user id, date, and comment text and store it in an Access table. Those fields could then be retrieved by some more code. This would allow any user to see all comments by any other user related to a specific WO.
I'd greatly appreciate feedback ... on the practicality, preferable constructive, but brutally honest is ok too.
Much thanks,
Kevin
Apart from this being a horrible mess you could:
use SQL Server instead of access - you can get a free copy that will probably cater for your needs. Access will also work, but it is bodge. SQL server is more professional!
I would avoid doing data entry in excel. You could build a front end (possibly in Access with SQL Server backend) that allows data entry. You could add pretty simple code to all your workbooks, which will probably reference code that will be in an excel addin. The addin has code to simply open an access database, open a form and find the WO that the user was viewing in excel.
2a. Or you could use an excel addin with a data entry form, to do data entry, but beware managing the locking, refreshing and update of displayed data.
Creating excel addins is easy, (re-)distributing them is easy, access (or whatever front end you use) is designed to do record management (ie lock and update or lock and cancel or just view) etc.... Plus you want to avoid addinghte same or similar code to all your workbooks.
Each users workbook would have very simple code. Just to tell the addin what WO you want to operate on.
Do you have sharepoint? If so Access 2013 can deliver forms as webpages - very easily, so you might not even have to manage a front end access file.
Happier now?
For those that may stumble on this post, what we ended up doing was use VBA to store comments in a separate SQL database. Users double click the cell with the WO number to get an input form prompting for comments with options to add new, append or remove existing. Entries are passed to the SQL db and also to columns in the worksheet so users can see all the entries. Time stamp/Network ID provides when/who provided comment. Existing comments are fetched when users re-open file. Works great.
I have an SSIS (super)package that consists of several (about) 40 packages, each of which has several data flow tasks, most of them loading some excel data to a sqlserver database. So I have several excel source connection managers, one per excel file.
This has always worked fine until recently : I have to change an excel source in one of my packages (a column was added in the excel which has to be loaded in the destination sqlserver table) but I cannot edit the excel source in SSIS : when I click on "columns" I get an error box "DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER". So this is a design time issue, not a run time problem. I've seen a question like this one on stackoverflow but no answer. Anyone has an idea ?
I' ve already removed office 2007 and reinstalled office 2003 on my machine, but this didn't help
it has nothing to do with 64bit mode, which I've read about here
Is there some limit on the number of connection managers in ssis ?
Most of my connection managers were created with copy/paste and hence they have the same Id, although they point to different excel files. Could this be a problem ?
I should also mention that the package runs without any problems, so it's only "editing/changing" the package that doesn't work. For the moment I circumvent this problem by disabling the data flow that should change and by replacing it with a sql statement that hardcoded inserts the data from the excel into the destination table.
Maybe another intersting thing to mention : I can create a new package and add and change excel sources without problems, but then again, when I try to copy this excel source in my package, I cannot edit it.
Did you try to check the advanced options on the Source Connection?
Right click on the component and select "Show Advanced Editor..."
Select the column mappings tab and press the Refresh button.
This should point out that the XLS connection has some additional columns or that the file that you are pointing at, cannot be pre-validated at runtime.
M.
I'm not sure if this will work but try the Work Offline option in the SSIS menu in BIDS/VS. What this should do is not validate the connection before you edit the component. It might be able to get you into the component.