An old Access database front end for my Dad's business is giving me problems after he updated to the 2016 version of Access. The front end is managed by some forms and macros and reports that point to a backend file which actually houses the database.
The issue arises when attempting to print reports (see attached screenshot)
The form maintains focus and won't allow for any interaction with the ribbon or the report windows it opens up so the reports can't be properly read inside access (cause the zoom level is too small) nor can they be printed reliably.
The front end was originally programmed in the 2003 access format but migrating the files forward to the newer .accdb format don't seem to help. Is there a flag I can change or macro I can add to allow for focus change from the form?
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 hardly dare bring up this topic because what is happening is so extremely strange - but I'll try anyway.
I have a large Access DB for a customer. One of the forms in the front end has a series of subforms. Until recently, everything was working well.
Now, when a new version of the front end is sent to the customer (I tried Team Drive as well as WeTranser) this results in one of the subforms being changed to a different form. This form is also in the database but is by no means linked to the main form in question.
I have tested this several times: The version on my PC is still working perfectly. The version that the customer sent back to me according to my request has the wrong subform in it.
We are all working on Access 2010 with an Access 2000 format MDB. The reason for this is that the Backend needs replication.
Does anybody have a clue on how or why this could be happening? Thanks in advance.
Found a solution myself after testing together with the customer.
Copied the file via USB stick this time. The copied file was OK on the destination system. Opened file pressing shift button so no programs would run. Everything was still OK. Then opened the file in the usual way. The start form realized that the paths had changed and relinked all the tables. Except for the start form, no other forms are involved in this operation. After that, the subform had changed to a different form.
Solution (rather: Workaround): Changed the name of the subform that replaced the correct subform. After that, everything went well.
The change of the subform only occurred during the relink routine. If the subform was changed to the correct one manually after relinking, it remained correct.
Reasons? Has Microsoft released updates to MS Access recently? We'll probably never know.
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 Access database for which I have created a 2010 runtime version.
I sent over to a partner in India where their predominant machines only have Access 2007 installed.
They have installed Access 2010 Runtime to these machines, but make the following claims:
No access to Nav Pane - to see/open tables
No menu ribbon
No table/datasheet right-click functions (sort, find, etc.), except as I have implemented under buttons on the form.
I see all these functions when I run on a 2010 VM. I don;t have a 2007-only machine to validate or debug their claims.
Does this result sound odd?
I suppose I could work around some of these:
Populate the current list of tables in a listbox on the form
Create a custom menu with the necessary functions
Not too sure about the table/datasheet right click functions
Not freaking out just yet, but getting close... I cannot re-build this thing DOWN to 2007.
Any advice anyone?
Does this result sound odd?
Not really. It sounds like you were opening the .accde file using the full Access 2010 application while the other team was opening it using the Access 2010 Runtime.
The Access 2010 Runtime environment does not include things like the standard ribbons, navigation pane, etc.. If the developer intends to deploy the Access application under the Runtime then the expectation is that they will provide custom ribbons and navigation tools as required for that particular application.
Note that this is true whether the Access application is distributed as an .accdb file or an .accde file. An .accde file is simply an .accdb file with the VBA source code removed and the users being prevented from opening objects like Forms and Reports in Design View. Those changes help "lock down" an application when opened in the full Access application, but they don't make any difference to the behaviour when opened in the Runtime environment (because the users can't perform those operations in the Runtime environment anyway).
Developers can test the "Runtime" behaviour of their applications by opening them in "Runtime mode" in the full Access application. This can be accomplished in either of the following ways:
Create a shortcut that invokes MSACCESS.EXE with the /runtime switch and passes the name of the .accdb file to open.
Temporarily rename the .accdb file to .accdr and open it. .accdr files automatically open in Runtime mode.
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.