Presently am working with an Excel spreadsheet that makes at least 10 database queries to external Microsoft Access *.mdb files. For each project my company works on, we have a specific excel file related to that project, so we have hundreds of these files. Usually when an analyst opens the Data tab and click on "Refresh All" the refresh completes in a minute or two; however, on a new project for a given excel file it is taking at least an hour to complete the refresh. Here is an example of one of the connection strings:
DSN=MS Access Database;DBQ=W:\Projects\Analysis\project.mdb;DefaultDir=W:\Projects\Analysis\Analysis;DriverId=25;FIL=MS Access;MaxBufferSize=2048;PageTimeout=5;
And here is the associated query:
SELECT Field.FieldNumber, Field.FieldName, Field.GroupMnemonic, Field.ClientFieldID
FROM Field Field
ORDER BY Field.FieldName
I have spent time studying various websites discussing slow excel issues like http://msdn.microsoft.com/en-us/library/ff700515.aspx; however, these websites deal more with calculations and VBA whereas I suspect the performance problem is somewhere in an access file. Does anyone have any suggestions on how to troubleshoot and resolve this issue? TIA.
UPDATE: As suggested in the answer below by JohnFx, I checked the queries and found that they had no definite keys, so and so added keys in the Microsoft Access database generation like this:
CREATE UNIQUE INDEX PIndex ON [myTable] ([KEY])
Run the queries individually directly in Access to rule Excel in or out as part of the problem. If the queries are still slow in Access consider adding indexes on any columns that are in being sorted or filtered on.
Related
I ran into a multi-user related problem in my MS Access application.
I have a split database, with multiple front-ends and multiple back-ends. The file locations of the backend databases are stored in an Excel file. The front-end contains a combo box, of which the source is a query that reads the data from the excel file:
This enables the users to switch between the different be-databases.
SELECT XL.*
FROM (SELECT * FROM [Speicherorte BE_DB$] AS xlData IN 'Z:\LocationXYZ\Speicherort_BE_DB.XLSX'[Excel 12.0 Xml;HDR=yes;IMEX=0;ACCDB=Yes]) AS XL
ORDER BY gemeinde;
However, I noticed that doing so, this doesn't allow for multiple users at the same time.
Error: "External table is not in the expected format"
This error does not occur when only one person is using the application.
Does anyone have an idea on how to fix this? Maybe only query the excel file once upon startup and then have "static values" in the combo box for the rest of the time?
Thx in advance and best regards,
Michael
I have a fairly complex database that has worked for quite a while. Today I went to troubleshoot something and I got a non-sensical error.
In my macro, first I create detail tables. Then I number each row sequentially in the detail table with a VBA script. Then I create a summarized version of that table including the just the key info like SKU and row number. (The rest of the details are added back later using the row number). The numbering script is working. The detail tables have the row numbers. However the summary table does not have the row numbers after running the macro. If I manually click the queries to add the summary tables, the numbers magically appear.
Please help. This database has worked for over a year without this problem.
Honestly it sounds like its corrupt. MS Access uses the Jet Engine which is known for bloating dB size and quite easily becoming corrupt.
You can see by the odd behaviour, the program is having trouble with the underlying file. If you open a new Access DB it won't exhibit the same problems.
The best bet is to recreate the dB from scratch or port it to SQL Server, PostGres, MySQL, SqlLite etc and put the application logic in a program - even if its a VB6 app, though I'd recommend .Net.
I've got the code to strip out every thing and recreate the MS Access dB here:
https://stackoverflow.com/a/16158027/495455
I am tasked with fixing some bugs that an access 2010 database, written 10 or so years ago, has. The database has been functioning but has a few bugs in report generation that need to be fixed (ie: bugs are not impeding overall functionality).
Since I am relatively new to access 2010, I wanted to create a working copy of the entire database, VBA and all, so that I could get into the VBA code and figure out what is causing the bugs without accidentally sending some of the automatic emails or changing pertinent information in the data. I have tried saving the database with a new name, copying it in the folder and pasting elsewhere, and creating a backup and saving that elsewhere.
Each attempt yields the same issue: the VBA project not being readable. It gives the following message when I open any copy:
if included picture doesn't load: tl/dr: database cant be opened because VBA project cant be read, if "ok" is clicked vba project will be deleted..I have searched high and low, asked everyone that has used the database, nobody knows how to fix the issue and I do not feel comfortable changing anything in the live copy.
Any assistance would be greatly appreciated. Thank you in advance.
One option you might try is to create a new blank database file and attempt to import all of the database objects from a copy of your target database into the new database file using the import wizard. If that's successful it won't be an exact replica of the previous database with regards to settings, but will include all of the database objects/code at least.
So I have an excel spreadsheet with Product and Notes. I'd like to import this information into SQL and everytime people enter more products and notes into this excel sheet, it will automatically updated to the new one whenever I run the syntax?
I finished creating Product - Notes, which I imported current data into that table.I was planning to use insert into function, and every day insert the new values in the table. But this seems too manual.
Is there a way i can do this? The excel spreadsheet is updated daily.
I'm using SQL Server 2008
I'm sure this is possible. You could have the excel connect to your database and then write some macros to save the data to the table when there are changes or new rows are written.
It would not be easy. There is a lot of complicated logic here and excel was not written to be a front end for a database.
I believe the time spent changing your spreadsheet to work this way would be better spent actually writing a client server application to modify the database using a web application or a local application. Client server front end applications are easy to write these days with lots of examples, tools and templates. For someone with experience a simple data entry / modification form is just a couple of days work for a robust application.
Changing the excel file would be much harder.
You could use SSIS to import the excel data into your database on a scheduled basis.
I have an Oracle 11G database and sql developer 3.0.04. I have a SQL query which collects useful data for users across a system. The query prompts for two values (using the "&" trick) and then returns a number of columns and rows reflecting their choices. For example, entering "2" at the location prompt, will use the sql query to pull revelant data for that particular location only.
I can connect to the database using Excel 2003. (ODBC Connect) I want to store an excel file on the server, that my users can access to run this query - (as sql developer wouldn't be suitable for these users, too complex)
We have Excel 2003 installed. What do I need to do to let users run the sql query from excel, which will show them the result also in excel?
Thanks!
For what it's worth...
I'd recommend just turning this query into a report in SQL Developer. There's nothing complex about that for your end-users -- they just click on the report they want to run, and it runs (output looks like a table, and they can export it if/as they choose from there). Distributing the report simply requires that you store on a share drive or email it to them (then they import it) -- it's a lot easier than it sounds, and also very convenient for distributing updates / additional reports. With reports, your users won't have to see the SQL, for example (unless they really want to), and the prompts will appear to them as little dialog boxes with plain-english messages (whatever you want them to say).
Anyway, you might find this easier to support / modify / maintain, and I think your users should be happy enough with it (unless they're really grumpy types... :-)