I have an Access file which I wanted to change the design of. I did not create this file. However, when I open the file it immediately opens the switchboard form. I cannot see the side panel that I see normally containing Access objects like: tables, queries, forms, reports etc. Is this just a run time version where I cannot see other objects or is there a way for me to access other objects?
I have learnt about run time version but I had never seen it before so I am not sure what this is.
Related
Looked around quite a bit before posting this - I just can't seem to get this seemingly very simple question answered (I think I missing something!)
From within MS Access 2007 I have several related tables that deal with inventory of products. I simply want to export that table data into a SharePoint List (or Lists), and link them. Users will generally just use the SP lists in order to search, view, and sometimes modify the data (i.e. mark a product as exhausted). For our work group this is preferential to opening MS Access repetitively.
The problem I'm having is that the linking features within Access don't make sense to me! I seem to be missing something fundamental here, despite reading over the MS documentation and various sources.
One can export a table, but there is no linkage between the created list and the original table. Changes made on the SP list will not be reflected in the original table which makes this a lot less useful?
One can import a list, but that linked table that is generated is NOT the original data table that I started with (the new, generated SP-linked table is a different entity than the original table. Updates to that new SP-linked table are not reflected in any original table that I had). This method seems very backwards, as you ought to have your relational DB setup correctly before attempting to make SP lists that surface that data. It seems backwards to me to make SP lists that are then wedged into an existing DB without any consideration to the existing DB structure?
So - I think that there is something fundamental that I'm missing here. It would seem that one ought to be able to just use SP to surface/provide views/editing of existing Access tables.
Isn't there just a simple way to have a SP list directly linked to an existing Access table, so that changes in the SP list are reflected in the original Access table?
I believe the solution you're looking for is the ability to "Publish" an Access DB to a SharePoint site. If you're using SharePoint 2007, the published copy will be read-only in SharePoint but users can still do everything else you described.
Details on this type of Publish are in the Office Help here:
https://support.office.com/en-us/article/Publish-a-database-to-a-SharePoint-site-8287ed04-9c65-46c4-bbdb-c965c56b018c
To quote from it:
Click the Microsoft Office Button Office button image , point to
Publish , and then click Document Management Server.
Type the URL of
the SharePoint site where you want to publish the database. If you
used the same location the last time you opened Access, the database
appears in the Publish to Web Server dialog box.
NOTE: This option is available only if your database is saved in Office Access 2007 format.
Select the library, such as a document library, where you
want to publish the database, and then click Open.
In the Name box,
type a file name for your database.
Click Publish.
If you have SharePoint 2010 or newer, users in SharePoint can have full CRUD (Create, Read, Update & Delete) capabilities to both the data and even the DB design without having to touch Access once the DB has been published. This is described in more detail here:
https://support.office.com/en-us/article/Build-and-publish-an-Access-database-to-SharePoint-e68bf007-410c-43b2-bf21-322ddbcf5411
The steps to do so are simply:
Open the Access file
Click 'Save and Publish' in the File menu
Choose 'Publish to Access Services' under the Publish heading
Specify the URL to the SharePoint site you wish to publish it to
I have built my application but a problem has arisen that I cant get my head around - My application has no autoexec yet so I open access and double click on my userform to open it.
On opening the userform Access crashes and closes
However, if I first put the userform in design view, then open the form in form view it works fine.
How can this be?
It cant be the Form Load coding or it would still crash when going from design view to form view.
I will include my form load coding in case:
Me.LastImport.Value = DLast("LastImport", "tbl_Import_Export_logger")
Me.Text42.Value = Date
Me.Text44.Value = Date - Weekday(Date, 3)
'Compliance Reporting
Me.Text68 = DCount("[CustomerAccountNumber]", "Q_HealthChecksOverdue") 'Overdue Health Checks
Me.Text76 = DCount("[CustomerAccountNumber]", "Q_HealthChecksdue") ' Due Health Checks
Me.Text74 = DCount("[CustomerAccountNumber]", "Q_HealthChecksCompleted") ' Completed Health Checks
Me.Text72 = DCount("[LettersDueStatus]", "Q_LettersSent_Query") 'Count number of letters sent
(originally written on Stack Overflow Documentation)
How to troubleshoot Access crashes
When you receive an error: "Microsoft Access has encountered a problem and needs to close", there is often not a lot of information to help you identify the cause of the error. Below are a series of steps you can take to troubleshoot the cause of the errors.
Decompile Database
This should always be your initial fix. A good policy is to decompile the database before each release.
Create a decompile shortcut.
This loads the database with a "/decompile" switch.
Right Click your Database File. Select Copy
Right Click in the explorer window and select "Paste Shortcut"
Right Click the shortcut and select "Properties"
In the Target box, go to the end of the line and add /decompile
Click Ok to close the shortcut
Open Database with Shift.
Hold down the shift key while double clicking on this shortcut.
This prevents any auto runs from executing within the database.
You should go straight to the navigation window.
Compact and Repair the database.
Once the database is loaded, you will need to click the Compact and Repair button.
Locate the Compact and Repair Database button on the Tools Ribbon.
Hold down the Shift Key. Keep holding it down while you click the Compact and Repair button.
Recompile the Database
Go into the VBA window (Control + G)
Select Debug -> Compile from the menu
This is the complete decompile process. Generally it should fix 99% of all Access crashes or weird form behaviour.
Rebuild the entire database
This is a lot of work, so do this as a last resort after exhausting all other options. You only need to do this if the problem is occurring for different users, on different machines. If it isn't occurring for all users, then most likely it is not a corrupt database container.
Similar to the steps in removing binary data, you are going to rebuild your database from scratch. This process is a little ritualistic, but if done meticulously with care not to "preserve" any possible corruption, then the process is highly effective.
Create a new access database container.
In Access, on the File Tab, you can select "New". Create a new, empty database in ACCDB format.
Move all objects to the new container
Do not use the Import / Export functions within Access to move the objects, and do not simply click and drag. Doing this can copy the corrupt items over to the new container.
Tables:
For each table in the old access container, create a new table in the new container.
From design view, copy/paste the field definitions.
Check the table properties to ensure they match in both databases
Move any Data Macros over as well (see the Macros section for how to do this)
To move the data, export the old data to XML or CSV, and then import from that format.
Queries:
Load each query into SQL view.
Copy / Paste the SQL text.
Paste into the new database.
Compare Query properties to ensure they match.
Forms / Reports:
For each Form / Report, use the Application.SaveAsText function to export the forms/reports to a text file.
Remove the Binary Data (see Remove Binary Data from Form documentation to acquaint yourself with this process)
Use the Application.LoadFromText function to reimport the objects into the new database
Macros
You have three methods of moving the Macros.
Recreate each macro by hand in the new database container.
Use the Application.SaveAsText / Application.LoadFromText method with the acMacro parameter.
Copy/Paste Macro definitions for each macro
Select All (Control + A) to select all macro elements. Then Copy (Control + C).
Open a blank Notepad document and Paste (Control + V) the Macro XML.
Create a new blank macro in the new database container.
In Notepad, Select All text (Control + A). Then Copy (Control + C)
In the blank macro, Paste (Control + V). The Macro should appear. Save it.
Modules
For each module, select all code (Control + A) and paste (Control + V) into the new database container.
Be sure to check the Database Properties (In VBA Window, go Tools -> Client Properties)
Data Macros
For each Data Macro, use the SaveAsText / LoadFromText methods.
Go into the VBA Immediate Window (Control + G)
Type Application.SaveAsText acTableDataMacro, "MyTableName", CurrentProject.Path & "\MyTableName.txt" (Replace MyTableName with the name of the table containing the data macros)
Review the file for any signs of corruption
In the new database container, load the definition using Application.LoadFromText acTableDataMacro, "MyTableName", CurrentProject.Path & "\MyTableName.txt"
As previously mentioned, this is a LOT of work, but it has results. This method should also be used when migrating an Access 97 database to 2000, or an Access 2000 database to 2003.
Remove "OLE Object" fields
If you have images or other data stored in Access itself as OLE Objects, then you should find a better approach. When the OLE data is stored, it is stored according to the software (and version of software) on the computer storing it. When another computer goes to display that OLE Object data on the form, but doesn't have the exact software / version installed - quite often this results in an application crash.
If you are storing image data, then a better approach is to store the filename, and instead save the images to a standard location. Newer versions of access have the native controls to make this the way to go.
Remove Binary Data from Form
Sometimes the crashes occur constantly in a single form or report, or occur only when printing. It is possible that the binary data within the form / report has become corrupt.
Save the Form / Report object as text
There are two undocumented functions. Application.SaveAsText and Application.LoadFromText. You can use these functions to export the form/report definitions, clean up the definition, and then import it again.
Make a backup of your database before proceeding
Go to the VBA Immediate Window (Control + G)
Type Application.SaveAsText acForm, "MyForm", CurrentProject.Path & "\MyForm.txt" (Replace MyForm with the name of the Form / Report. Use acReport if it is a corrupt report you are fixing)
Rename the original form item (e.g. rename to MyForm.Bak) within the Database Window
Clean up the Form / Report Definitions file
Open the exported file (e.g. MyForm.txt) in notepad
Delete the "Checksum=" line (should be on line 3)
Clear out binary data
Identify the binary data blocks. Look through the file and you will see lines that start with "Parameter = Begin". Following those lines you will have lines of encoded binary data. Finally, the binary block will end with a line consisting only of "End". The Binary Data block includes the first line (with the Begin statement) and all lines up to and including the last line (with the End Statement).
Note: All of these blocks should appear BEFORE your form control definitions
Delete the binary data blocks for the following parameters:
NameMap
PrtMip
PrtDevMode
PrtDevNames
PrtDevModeW
PrtDevNamesW
Look for other issues. While you have the file open, scroll through the rest of the file and look for anything that catches your eye, especially in the VBA module code at the bottom. You will be looking for anything that sticks out from the rest, and may be corruption.
Save the file.
Load the form / report back into Access and Test
Load the form back into Access.
In Access, go to the immediate window (Control + G)
Type Application.LoadFromText acForm, "MyForm", CurrentProject.Path & "\MyForm.txt"
Decompile / Compact Repair / Recompile (See the other example within the documentation)
Open the form / report to test. Hopefully everything is working now.
Delete the old corrupt form (e.g. MyForm.bak)
Prevent this corruption in the future
The most common cause of corrupt binary data within a report / form is when multiple computers / users use the same database client file instead of having their own separate copy. This is why each user should have their own client file on their desktop that they run.
Test Computer Memory
If your crashes are random or sporadic, then do this step. If your crashes occur every single time you run the database, then this step won't fix the issue (although bad memory may be the reason why the corruption occurred in the first place).
Use a memory tester that boots outside the operating system and runs multiple passes. Two popular choices are MemTest86 (Commercial) and MemTest86+ (Open Source)
Start the test and let it run during working hours. The reason for this is because other factors in the building such as noise on the power circuits can cause memory errors, so you want to try to keep the variables the same.
If you have memory errors, then you will need to identify whether it is due to bad memory in the computer, or some other factor. This is beyond the scope of this document however.
Remarks
Be sure to remove other variables from the equation while testing
Network Corruption
Do not load the client off of a network. Put it on the local drive and run it from there.
Corporate Builds
If you are in a corporate environment that is using "computer builds" and have had no success with Decompiling, Testing Memory, nor stripping Binary data - then refuse to do further testing until the IT team can provide the user with a test machine that has only Windows, Office, and Service Packs installed.
All software and updates should be installed by hand without using unattended installs. Do not install antivirus on this machine for testing.
Understand that many IT departments simply try to do a One-Size-Fits-All approach with the builds, and their builds are all based on one another. Over time, software conflicts can directly cause Access to crash or act strange.
Bad Power
As mentioned in the memory example - power fluctuations can cause computer errors. If the database is in an industrial building, then try to get your hands on a power conditioner or a UPS that provides clean power (off the battery, not off the main passing through a Metal-oxide Varistor)
Also, check the power supply cable that is plugging into the power bar or outlet. Make sure that the gauge and voltage specs are sufficient. IT departments often leave power cables plugged in at the station and just remove the machine. After many years, they are using beefier power supplies, but haven't switched out the cable. It makes a difference. When in doubt, bring a new, thicker cable.
Thank you for all the replies. I didn't end up testing the suggestions you all mentioned.
In my case, in VB I ran debug and it highlighted 2 issues in my code so I sorted them, now it runs fine.
Thanks everyone
I am building an Access Database application in MS Access 2007 which is essentially a tool for data collection which I will need to distribute to various sites to be filled out. After the sites fill out all the necessary records, they will return the tool and I will need to merge all the data from the various sites into a single database for analysis. I have 2 tables and 3 forms with a bunch of custom VBA code behind for data validation, cleaning and flow.
I have a Summary form that shows all the records currently entered. Users can then Add a record using a button on the Summary form which launches a data entry form (let's call it Data Entry Form #1). From Data Entry Form #1, there is another form that can be launched (Data Entry Form #2) for entering child records about the record being filled out on Data Entry Form #1. There is referential integrity enforced at the table level.
The flow from the Summary Form to Data Entry Form #1 and Data Entry Form #2 is important for the integrity of the data. I have dictated this flow explicitly in VBA and will instruct users to always begin at the Summary Form.
After that lengthy background, my question.....
What are my different options, and the relative advantages/disadvantages for the options for deploying this application to my various sites. My basic requirements are:
Ideally users would never see the tables in which the data is being stored in.
The Summary form would launch when opened and they could not open any other form directly.
Closing the Summary form would close the application.
Since there is a bunch of VBA code dictating important functionality, if they did not accept the Security Warning, they would not be able to access any of the forms or use the tool
I can easily script the extraction/export of the data from the two tables for each tool
I am vaguely aware of the following options:
- Distribute the full ACCDB file to the sites
- Create and distribute an AACDE file to the sites
- Use the Access Developer Extensions to "package" the application - create and EXE file?
I have also read that if users do not have Access 2007 or later, that they can download the MS Access Runtime Services and be able to use my application without having to buy/install a full version of MS Access. Can someone confirm this? Does this apply to all of the above (ACCDB, ACCDE, EXE) Is there any functionality that would not be available to them from a strictly data entry role?
Thanks!
You should be able to do most of this with options set within access, plus some code;
Create an accde;
Using that accde, in the options, untick display navigation pane (or something like that); There should be an option to disable the shift key as well.
Set startform to the summary form
Closing the summary form closes the application: In design view of the summary form (in the accdb, before you do the rest of this), create a form_unload event; In this event put
DoCmd.Quit
More of an issue might be whether or not all the sites have the necessary components of ms office to run access 2007, or if you need to provide an access 2007 runtime as well, but I'm not going there. If you need to do this, you'd best ask another question or go hunting for an existing answer.
Hope this helps
If you do want to package the database as a run-time, the MS tools are notoriously flaky when it comes to deploying. A company called SageKey sell scripts that actually work, dealing with the issue of other versions of Access being installed, and many other things.
I've used about three versions of their scripts (ie. for three different MS Access versions), and they have been great.
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.
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.