I split a database and created a search form in the front end. It works there, but when I copy the front end, the search form doesn't work there
The form is a continuous form and has my table as a datasource. There are a number of bound fields in the detail section and a number of unbound fields in the form header. On the click of the search button, I use vba to build a sql select string and use Me.RecordSource = strSQL. Again this works in my original front end db. After realizing it doesn't work in a copy, I have tried copying and pasting the form from one front end to another, export/import, recreating it, hard coding a select, trying to display a message box on the click...nothing seems to work on the button click (tried double click too). If I build a button with the wizard, it will work, but they are using built in macros.
Any thoughts? Thank you in advance.
If no code seems to run in your new database (including MsgBox), then it is quite likely that the new database is in a folder that Access doesn't recognize as "trustworthy" and has therefore turned off code running.
Check that the folder where the database is currently located is allowed to run code, and if not add the folder:
File|Options|Trust Center|Trust Center Settings|Trusted Locations
Regards,
Related
I decided to "tweak" an existing database to further manage multiple sources of income.
I copied the working database and created a "modification copy", just in case I messed things up horribly.
In the modified version, I have a button on a form (in fact, two different buttons with similar macro properties, just directed to do the same function to different reports.
The properties are your standard macro with an openreport, and a "where" condition.
Here's the problem. The macro has worked in the past, and continues to work on my "pre-modification" operating database.
On the modified database, after ensuring all the parameter elements are entered correctly, I can change the "view" to report view, and the macro seems to work just fine until I close the database.
As soon as I open the database, the buttons produce an error. See pic below.
The only way I seem to be able to resolve this odd button macro issue is by going into design view and adding a new button. I've discovered...I don't even need to embed a macro, just adding a new button seems to renew the macro operation...until I close and reopen the database. Then, I have to add a new button again to get the open database's macro to operate.
I can delete the new button added, and still have the macro buttons work, until I close and open the tweaked database.
I have zero VBA coding knowledge. I use Access's macro building tools and typically have to visit sites like this if I need to learn a new "trick" to get my database and it's various tools to do something.
I recently explored with the "subform" that can be seen above in the open form pic with the error message. My guess is that maybe that subform is somehow causing my macros to continuously fail???
Thanks for any help!
Building a Maintenance log book in access. Had to redo a data entry form so I started over with a new form in a new database then copied some working code from the old form to the new. In doing so I changed the names of a couple of combo boxes in the new form in order to keep things consistent. Problem is, the code I copied has the old name of some of the combo boxes and I can't change those names to the new names. The new names don't present when using autofill, just the old ones. Is there a way to correct that.(Easy, I Hope)
Example: in the old form the name of a combo box was actionCB. In the new form the box is named ActionCB, but now any code I write uses the old name.
This might be happening because you have compilation errors. Try compiling the application and fixing any errors. Or possibly this could happen if you happened to be stepping through the code at the same time (but I doubt it from your description)? Also VBA is beautiful in the fact that almost always you can make code changes while stepping through the code... but I've experienced the changes not saving from time to time.
MODIFIED FOR NEW QUESTION
As to your second question below in the comments. You can view and select a Form or Reports controls by using the Forms Property Sheet. If you look at the combobox at the very top of the property sheet it lists all Form or Report controls. You can select these objects by simply selecting them from the combobox.
Access is not case sensitive
"Example: in the old form the name of a combo box was actionCB. In the
new form the box is named ActionCB, but now any code I write uses the
old name."
If you're code is not updating to reflect the "ActionCB" name automatically, then you're probably trying to reference it where it's not available. This isn't going to generate an error if you don't have Option Explicit statement at the top of your module.
It'll just assume you know what you're doing and assign it to a Variant data type.
Put Option Explicit at the top of all your modules, and the debug | compile untill all errors are fixed.
I got a form that works amazingly by itself, but the second I attach it to my navigation form. I start to get prompted for user input since this line
[Forms]![frm_addReceiveReportInformation]![cbo_PurchaseOrderID]
no longer works due to the current form becoming subform in the navigation form which was explained in
ACCESS 2010 Navigation Form Query Property
I can't seem to figure a way out of using the !form since I absolutely need to retrieve the ID from a combo box to update another combo box.
I tried multiple ways of using the !forms but I can't seem to wrap my head around how to retrieve my information that I am seeking.
I got the 2 way navigation menu(vertical + horizontal tabs). Anyone got advice or has encounter this problem in the pass, who can direct me down the right path.
To access a field inside a form, which is attached to a navigation tab, you should use the following structure:
[Forms]![YourNavigationTab]![NavigationSubform].[Form]![YourField]
Note: tested in MS Access 2013
In order for queries that contain form references to work, the form must be fully loaded. I think the problem you are experiencing is that the query in the Row Source of the Part Code combo is being evaluated before the form is loaded and therefore you are being asked to input the parameter value.
You can work around this by leaving the Row Source property of the Part Code combo empty until it gets focus for the first time, something like:
Private Sub cboPartCode_GotFocus()
If Len(cboPartCode.RowSource) = 0 Then
cboPartCode.[RowSource] = "Your Query"
cboPartCode.Requery
End If
End Sub
I sometimes just put a button on the navigation form which opens the desired form as a standalone form. It is probably not the neatest solution but it does work.
I am programming the On_Click method for the button labeled "View" in the first printscreen below. The method will load a form with data corresponding with the specific address id in the row containing the "View" button. This code worked perfectly when pointing to a target form called "Addresses". However, when I decided to rename the form "Address", I started receiving the following error message when clicking on the view button:
I did some research on the web about this error message, which lead me to try to delete any outdated references in the VBA editor. But when I clicked on Tools-->References in the VBA editor, I got the following error message:
It seems that MS Access' entries in the system registry might have been corrupted. But I am not certain of this because the documentation of this on the web is sparse and inconsistent.
Here is a link to the database on a file sharing site: http://jmp.sh/b/9Uyx6J2YzWbs8zPq2h6g
If the problem is in the database, you can recreate the problem by opening the form "Main" and clicking on the button "View" for the record shown in the printscreen above, or for other records.
Can anyone show me how to get past this error message?
my advices?
You could rename your Forms!....SourceObject to "Address" instead of "Addresses"
You could copy/paste the form, delete the original, and retry
You could install a decent debugging tool like MZ-Tools for VBA, that will help you manage your errors. Check the details here
EDIT: I used to get similar bugs years ago, when I was writing specific form event procedures. As we decided to switch to a model where forms did not need to be debbuged anymore (check this here), we stopped getting this kind of message. And I think I forgot the trick we used to solve this kind of error. If I were you:
I'd try to open another access database and import all objects ...
I'd put aside/cancel the faulty onClick procedure
And I'd install MZ Tools because otherwise VBA debugging is a nightmare ...
Since access was not liking the command button in each record of the continuous form, I choose to put the view button's logic in the on click event of a text box in each row, which I configured as enabled but locked. This produces a separate link from each record of the continuous form to a unique detail page with more of the chosen record's data.
This solution works perfectly, and is enabling me to move on with my other coding.
However, it would be nice if someone else were able to show how to get the command button solution to work.
So I have an Access database with a front and a back end. I will be distributing it to users soon, but I have no control over where exactly they will put the files on their computers. However, I think I can count on them putting front and back ends in the same folder.
As such, when the front end opens, I want it to check that the linked tables are correctly connected to the back-end database. I have working code for this; however I don't know where to put it. When the front end opens, a menu form is automatically opened (configured through the start-up dialogue box). I have put the code in the OnOpen event, which I thought occurred before any data is loaded, but when I test this out, I get a message telling me that the back-end cannot be found (it's looking in its old location).
Basically, is there an event I can use that runs before any forms have opened?
Create a Macro and name it "autoexec".
For the macro action, select "RunCode" and then set the function name to the name of the function you use to check your linked tables.
As Matt said, create a macro, call it "autoexec", and select "RunCode" as the macro action. The Function Name argument should be the name of the function you wish to run (and not a sub), and if the function has no arguments, you should still put () at the end, or it won't work.
I generally prefer to create a small form that runs a number of checks, such as finding the back-end and so forth, and set various options. The code for the open event of this form might be:
Me.Visible = False
'Determines if the database window is displayed
SetProp "StartupShowDBWindow", False, dbBoolean
'Hide hidden and system objects
SetOption "Show Hidden Objects", False
SetOption "Show System Objects", False
'Find back end
CheckLinkPath
I keep a table of tables to be linked in the front-end and if any are missing, this form can be used to report the error, or any other error for that matter.
Set RS = CurrentDb.OpenRecordset("Select TableName From sysTables " _
& "WHERE TableType = 'LINK'")
RS.MoveFirst
strConnect = db.TableDefs(RS!TableName).Connect
If Not FileExists(Mid(strConnect, InStr(strConnect, "DATABASE=") + 9)) Then
'All is not well
blnConnectError = True
Else
Do Until RS.EOF()
If db.TableDefs(RS!TableName).Connect <> strConnect Then
blnConnectError = True
Exit Do
End If
RS.MoveNext
Loop
End If
If everything is ok, the small form calls the main menu or form and the user never sees the checking form. I would also use this form to open a password prompt, if required.
Before putting your front end and back end in the same folder, think about it. Isn't it worth having 2 folders? What about multiple users on the same computer accessing the same back-end database? What about multiple users accessing the same databse through a network? What is the necessity of having a front end-back end typology if your app is basically a single-user app?
Why don't you add a dialog box to your app, in case your connectivity is lost? You could create a fileDialog object in your code, allowing the user to browse for a *mdb file anywhere on his computer/network. It is then possible to control that the selected mdb file contains all requested tables and open the corresponding links (I guess you are using the transferDatabase command).
And what about additional tools/references you'll need for your app to run when you'll distribute it to your final users? By default, MS Access records the 3 basic ones:
Visual Basic For Application
Microsoft Access Library
Microsoft DAO Library
If your app needs anything else, such as ADO or Office objects (ADODB.recordset or Office commandbars for example), you will have to add the references manually for each installation, as the final user won't be able to open the VBA window and access the tools/references menu.
So, if you need to deploy your app on multiple computers, I strongly advise you to use a deployment tool such as this free one. You'll need a few hours to be able to use it properly, but the result is worth it. You'll be able to give your clients a real installer module. It will create folders, add requested shortcuts, and manage references in the computer's registry. This will make your deployment definitely painless!
EDIT: the autoexec macro is definitely the right solution for calling code before any event.
EDIT: don't forget that your final users can make profit of the runtime version of Access, which is free!
As others have suggested, I'd use the AutoExec macro in this case. If your code that checks the linked tables is currently a sub, change it to a function that returns TRUE if it succeeds. You can then use the "conditions" column in the AutoExec macro to exit the application with a user-friendly error dialog if the link table code fails. Your AutoExec macro could be something like:
Call your LinkTables() function, set condition to terminate startup if it fails.
Call your "Main" startup menu form.
You could send them a *.BAT file that copies the databases to c:\temp (or whatever folder you choose. Setup the linked to this folder before creating the BAT file. Zip it up and email it to them. then you won't have to worry with the extra needed code.