I am updating a MS Access away from access. There are some Append Queries that the design view will not come up at all. I read somewhere that if the append is extra old you just need to save the DB as an older version. However, that also fails to do anything.
I am using O365 Access with a 2007-2016 file format DB. It has been upgraded multiple times over the years I would assume it might've started as a 2000 DB.
What can I do to see the design of the append?
If you open the Visual Basic IDE (Alt+F11), and then open the Immediate Window (Ctrl+G), you should then be able to enter the following expression on a new line in the Immediate Window (changing Query1 to the name of your query) and press Enter to view the SQL associated with the query:
?CurrentDb.QueryDefs("Query1").SQL
You could then inspect the tables/queries referenced in the SQL and see if anything is amiss, or copy the SQL to a new query to see if it exhibits the same behaviour.
Related
The Problem
I have been encountering a problem with MSAccess 2007, with a 2003 format database.
When I try to run the query (for example a select query), I get the message "The Microsoft Office Access database engine cannot open or write to the file "query name". It is already opened exclusively by another user or you need permission to view and write its data".
In addition, I cannot view the query in design view, only in SQL view. This only happens for certain queries, which I was previously able to design and change with no issues.
What I have tried
I have tried Repairing and Compacting, and that does not fix the problem. The only way I have been able to fix so far is by importing all the objects into a new database, which has resolved the problem for a while, then a few days later the same issue happens again.
If you are in a multi-user environment, and the back end database is on a share drive, this will happen when someone else opens the back end database directly from the shared drive instead of using the local front end database. If the back end database is opened directly from the shared drive, other users will be unable to use the front end database due to locking issues.
I have a Microsoft Access MDB file on a website to which an ASP classic code adds rows.
How do I create a query/module that will run every time I add a row or automatically once a day?
If you're looking for something to run when a row is added, you're looking for "triggers" - which is not available in Access*. You find that sort of thing in proper RDBMSs like SQL Server, MySQL, etc.
If you're looking for something to run once a day, you could create a small VBS/PowerShell/etc. script and set up a scheduled task on the server to run it at an appropriate time.
You could also run the query in response to a page. If this is something that you want done after insert, then you can append the appropriate code to the end of the page or have it run as a part of the "success" page (if you have one).
* Unless you are using a .accdb (Access 2010 and later) file and the appropriate drivers. Then it appears you can use Event-Driven Data Macros to get the same effect. Thank you Gord Thompson.
I have a MS Access 2010 DB with bunch of forms,queries ,macros, Reports etc
The data for my report comes from ODBC links to SQL Server 2000 Tables via linked table property.
Now, whenever i goto design mode of a report,Everything moves painfully slow (I have to wait atleast half a minute for every mouse click,or to select a text box , or any operation performed on the report)
The report itself takes about a minute to run.Which i dont mind.
All I am looking for, is a quicker way to make changes to the design of reports.
This is an old question, but I had a similar issue with form design running extremely slowly recently. For me, only one form seemed to be affected (all others ran fine in design mode). The record source for the form was a complex query built on a hierarchy of subqueries. I dumped the query results into a table and used the table as the record source for the form instead of the query. This appears to have resolved the issue. Hope this helps someone else.
I found the main cause to be the Access conversion program that converted 2003 format to 2010. If you create a new .accdb and then import all of your object, it should work OK. I definitely fixed my issues
What worked for me is based on the answer provided by Albert Kallal at http://www.utteraccess.com/forum/lofiversion/index.php/t1959800.html.
For me, in my split database, if I open any table that is linked to the backend then opening any frontend form or subform was very quick. If I do not have open and keep open a linked table, then it takes about 20 seconds to switch from Form View to Design View and another 20 seconds to open a subform, etc. When I have a linked table open (it does not matter which table, just any table linked to the backend), then it takes about 1 second to do any of those functions. Huge difference!
That is not normal. Something is wrong. Could be your Office/Access installation, your OS installation, something taking up too much of the system CPU, or your system just not having resources, like memory, to properly run Access. Or that your DB is corrupted and/or bloated.
Two tests you can try.
First, do a compact/repair on the DB and see if that fixes it.
Second, is to start your computer in Safe Mode and see if Access still runs slow. This will test for much of the above issues.
What worked for me was to change the subdatasheet name from 'auto' to 'none' on all local tables. Do this in the property sheet in table design mode. There are routines posted elsewhere that will find all your local tables and change this value.
A table was linked to an Excel file. I found that when the Excel file was open, it took forever to change to design view on ANY form. Closing the Excel file eliminated my problem!
My case is access work fine in every function except opening or designing report. But access can work fine when network disconnect. I found it's cause by printer share by other computer and the computer which was removed. I remove the printer from control panel and access can work smoothly.
I have an application that creates an Jet database at run-time, and imports ~100k records so that I can make use of the indexing for performance reasons (1 minute versus nearly 10 when not using a Jet database).
The database is created using ADO Extensibility in Excel, and everything works just fine. However, my issue comes whenever I then open the MDB file in Access front-end, it automatically starts to "repair" the database.
The data is still fine after the "repair", however my main output query can not then be viewed in Access as it tells me it cannot represent the joins, and if I then view it in SQL the required joins are not there, and the query can no longer run. This still happens if I let it get "repaired" but do not open that query, i.e. it is the "repair" that breaks the query, not the act of trying to view it in Access. The funny thing about this is that I used the Access GUI query designer to construct the SQL as my life is too short to worry about it's crazy bracketing style, but it then later decides that it's too complex for itself??
Also, nothing else appears to be affected so I can only assume it's this one query it doesn't like.
This isn't a deal-breaker for me as my fix is to make the MDB hidden and advise users who can see it not to open it.
However, I would really like it if the database could be opened and I didn't have to hide it away like that. Therefore, my question is whether there is any way to prevent the MDB being "repaired" automatically?
Thanks!
Microsoft Access is "repairing" the file when opened because it is missing some tables that are specific to the Microsoft Access user interface. Since you created the MDB file directly using OLEDB with Microsoft.ACE.OLEDB.12.0, these tables are not present, and must be created when Access opens the MDB the first time. There are several ways you can circumvent this:
1) Name the MDB something other than .mdb - e.g.: MyAccessDatabase.mad - this will prevent Windows from using Microsoft Access to open the file.
2) Use COM+ to open an instance of Microsoft Access, and have it create the .MDB file. This .MDB file will then have all the necessary tables present and will not need to repair the file.
FYI, whenever Microsoft Access opens an MDB that needs repairing in this fashion, it will inspect all the QueryDef objects for invalid SQL and correct them as necessary. This is why your "complex" query is breaking.
Has anyone else come across a situation where the contents (SQL statement) of an Access 2003 or 2007 was completely wiped (the Query object still exists, the inner SQL does not)?
Does anyone know what causes this?
I've just had this happen to me again. 2 queries run from a Macro's OutputTo actions to generate 2 Excel files. I ran the Macro a few times then suddenly no more SQL statement in both Queries.
No, I've never seen this happen. And I've read pretty much all the postings in the Usenet and Microsoft newsgroups mentioning corruption for the last ten years or more.
But I'm wondering. Do multiple users share this MDB? We've had a few bizarre postings with respect to Access 2007 losing VBA code.
I have accidently done this in VBA code in MS Access by creating QueryDef object whose name that matched an existing query.
Yup I've had this happen in a 2003 database - I thought perhaps the database had been corrupted so I rebuilt it from scratch this time using Access 2010, but it has just happened to me again. Macro / button has been working as expected for months, but after I changed 1 line of VBA code in a completely unrelated part of the application (setting a field to null instead of ""), this query wiping has started again.
I run a macro triggered from a button which outputs the results of a SELECT to a file. I've worked out the specific steps I can take to trigger the Query being wiped out, however if I check the query still exists in between each step then the query doesn't get wiped! Obviously this is not a solution for the application users.
I have found in another stackoverflow question Weird Bug: "DoCmd.OutputTo acOutputQuery" is deleting the query a work around I am going to try - change the built-in macro ExportWithFormatting to run code instead and restate the SQL before running the output command.