I am trying to update an existing Switchboard in an Access database. When I click the "Switchboard Manager" button, I get the error "Invalid Procedure Call or Argument." Any ideas what might be causing this or how to fix it?
The switchboard manager stores your settings in a table named Switchboard Items. Open that table in Datasheet View, and see whether you can spot any stored values which don't make sense. Sorry, I can't tell you specifically what doesn't make sense ... hopefully you'll know when/if you see it.
Actually that error message sounds to me more like a problem with the form itself. So rename the form and table, and create a new switchboard, which will also create a new copy of the Switchboard Items table.
If that new form/table combination works correctly, delete or rename the new copy of Switchboard Items. Then rename the old saved version of that table back to Switchboard Items again and try it with your new form. If the problem was solely due to the form, your new clean copy of the form should now work with the original version of Switchboard Items.
Note that many Access developers avoid the switchboard manager. It is limited and brittle. You can substitute custom forms which command buttons for your menu options. That may seem like more work, but it's not a huge amount of extra work, and you will be protected against switchboard manager breakage.
Related
I am developing an MS-Access application with the data sitting in a separate backend database (Also MS-Access). The main form contains a button to open a settings dialog, an exit button (both in the form header) and a navigation control with a number of tabs showing subforms in form details. The settings dialog is a popup. In the dialog the user can change the path to the backend database and all linked tables will be relinked automatically if the user saves settings. This works all very well.
However, after closing the dialog, requerying the active subform has no effect, only if I close and reopen the form (e.g., by clicking a different tab) would it show data from the new (relinked database).
And I think this has somehow nothing to do with my relinking vba code.
I tried to open my subform directly and used the Linked Table Manager, with the same result. Hitting the refresh button on the ribbon does nothing, only when I change to design view and back to form view, the data in the form would be updated.
I also tried different combinations of repaint, refresh and requery, but to no avail.
I use requery extensively in my code and it works well, but it seems not after a simple reconnect of linked tables. The different backend databases have the exact same structure, they are just duplicates with some records removed to have test cases.
What's going on here?
Regards Oliver
Thank you Jeffrey, Your answer pointed me in the right direction. I wasn't aware of the SourceObjectproperty. This is, however, a property of the subform control that holds the actual subform. In my special case of a navigation control, it is the navigation subform control that holds the active subform which is defined on the tab as NavigationTargetName.
So my code looks as below:
' ContentContainer is the NavigationSubform control
srcObjStr = Me.ContentContainer.SourceObject
Me.ContentContainer.SourceObject = ""
UpdatePathes 'Relinking
Me.ContentContainer.SourceObject = srcObjStr
There isn't even the need to requery. Very nice.
Regards Oliver
I think if you use the SourceObject property of the subform instead of binding them you could force an update without closing your forms.
Form_myForm.mySubForm1.SourceObject = ""
Form_myForm.mySubForm2.SourceObject = ""
run your relink routines
Form_myForm.mySubForm1.SourceObject = "mySubFormQuery1"
Form_myForm.mySubForm2.SourceObject = "mySubFormQuery2"
Form_myForm.mySubForm1.requery
Form_myForm.mySubForm2.requery
This is just speculation, I've never had a situation where I needed to relink at runtime, but I think it should work.
I want to allow user to update data from form, but not from direct table. I added Before Change event on table, and raising error if the user group is 'basic'. This is working as expected if I enter data in table. But, it is also raising error even if saving data from form. Can anyone help me to resolve this issue?
Thanks in advance!
In general the way to deal with permissions in Access is to only ever show your users the forms; they should never directly interact with a table or query. So instead of adding Before Change code to your table, you instead want to hide the table.
The things you need are in the Current Database section of the Access options. For this example I'll assume you just have the one form, but the same applies if you have many forms and a "Home" form.
Use the "Display Form" dropdown to select the form you want the user to see when they open the application.
Un-check "Use Access Special Keys" to prevent keyboard shortcuts showing objects you don't want shown.
Un-check "Display Navigation Pane" to hide the object list.
Un-check "Allow Full Menus" to prevent users from creating new objects (or use other database development functions)
With this done, the user will see only the form interface you selected and the basic data entry toolbar.
Note that when you want to make changes to the file as a developer you must hold down Shift when opening the application, which will display the navigation pane etc. Of course, any user who knows about the Shift override could do the same. Which is why distributing in a compiled accde, which cannot be unlocked, is a good idea. But you need to set up the application using the above options before that matters.
I'm trying to change the schema of an Access 2013 table. I want to lengthen some of the text fields. When I change the schema and try to save I get dialog with Operation is not supported for this type of object, and a note that This property cannot be modified in linked tables. That makes sense. So I go to the relationships and try to delete one of the links. This gives me the error: You can't delete a relationship inherited from a linked database.
I don't know of any "linked databases" (I didn't create the database). Is there a way I can figure out what/where these might be?
Examine the TableDef properties for your linked table.
Here is an Immediate window session which examines properties for a linked table named remote_Foo:
' Connect identifies the database source of the linked table
? CurrentDb.TableDefs("remote_Foo").Connect
;DATABASE=C:\share\Access\BigDb_secure.mdb
' SourceTableName is the remote table name
? CurrentDb.TableDefs("remote_Foo").SourceTableName
tblFoo
You can use Ctrl+g to go to the Immediate window.
In Access 2010, that information is also available from the Linked Table Manager, which can be opened by right-clicking a link name in the Navigation pane and then choosing it from the shortcut menu. I don't know whether that option has changed in Access 2013.
You will need to make your design changes on the table in the remote database. Then recreate the link or use its RefreshLink method so that Access will recognize the design change and update the metadata it maintains for that link.
Your Table must be linked to Sharepoint site.
Go to "External Data" field and click "Work Offline" button (its a toggle button).
Make any schema changes.
Click again work online tab to sync changes to sharepoint.
I created a Shared Dataset in report builder 3.0 a week ago and stored in my "My Reports" folder on report server.I removed it the other day; however, when I go to create a new Dataset today...it's still listed as an option. When you attempt to select it from the list you receive an error message that it's no longer available. Below is the error which I am getting :
"The shared dataset cannot be loaded from the server".
Please help if anyone has faced a similar issue and know the reason for it. Thanks in Advance !!!
Ren is more or less correct, Report Builder is caching a list of items you've recently used. It does not bother to check if the items it's caching actually exist or not, which is why you're getting the error you do when you try to use one.
To clear the list, click the big icon in the top left (or alt + F), then click the Options button at the bottom of the dialog that appears.
In the options window you can clear your recent item lists, along with change some of the rules for how those are kept.
I don't believe there's any way to make Report Builder automatically remove broken/missing references
We have an MS Access 2007 database with a simple form displaying table data. We use the Find dialog (click the binoculars on the Home ribbon) to locate records we want. This can cause an error under specific circumstances.
Steps to reproduce the problem:
Open the form.
Open the find dialog.
Edit some field within the record.
The record is now in update mode
(you'll see the pencil in row's
"gutter" area).
Without saving the record, click on
the ALREADY open Find dialog.
Search for a record that can't be
found.
Click on the form again. The record
is still in edit mode (i.e. the
pencil still shows). Attempt a save
or edit some other field.
This message box will display
"Update or CancelUpdate without
AddNew or Edit." You can click OK or
Help buttons.
Clicking the Help button shows:
You tried to call Update or CancelUpdate or attempted to update a Field
in a recordset without first calling AddNew or Edit. (Error 3020)
On a Microsoft Access database engine database, you called the Update or
CancelUpdate method but did not use the AddNew or Edit method before writing
data to a record.
On an ODBCDirect database, this error occurs when you attempt to write data
to a record without first calling AddNew or Edit.
We’ve reproduced this in a new database where there is no VBA code. So the problem is solely within MS Access, and you should be able to reproduce it easily.
If you save the record before doing the find, the problem doesn’t happen. Unfortunately, we have users doing a find while the record is still in edit mode.
We’ve tried setting up form-level, data-field-level, and Access application level events and error handling. Nothing can detect or catch this situation. There is no way within VBA to detect if the Find dialog is active.
Does anyone have any ideas for preventing the error or a way to save the record before the find occurs? Our best thought right now is to create an AutoHotkey or AutoIt script that waits for the Find dialog to have focus. We’ll then send a Ctrl+S to save the current record to force a save.
#CodeSlave's answer suggests a possibility to me:
Instead of simply removing the binoculars from the toolbar/ribbon, instead change what the binoculars do. That is, have it call code that saves the current record if it's dirty and then launches the FIND dialog.
Now, there'd need to be some code to check that a form was open, and that it had a recordsource (testing the .Dirty property errors if there's no recordsource), and that a field has the focus, but all of those things are doable. Likely many of them (except the last) would be taken care of by showing the toolbar/ribbon only when the form is loaded, or by editing the default toolbar/ribbon when the form opens.
But this would be much less crazy than using an out-of-process solution, and your users wouldn't know any difference.
I'd suggest that you've found a bug that was introduced in MS-Access 2007. However, I have not been able to duplicate it on my copy. I presume we're both up to date on our patches, so perhaps there is something more subtle happening.
If you're wanting to force the record to be saved, use one of the the following - not a CTRL-S
if me.dirty then Me.Dirty = false ''(n.b. often the preferred method)
Docmd.RunCommand acCmdSaveRecord
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70 ''(n.b. deprecated)
The problem as I understand it, is that if they edit the form after the "find" is already open and then do the "find" the get the error.
I'd try one of two things:
Find a way to close the built in find form, and do so whenever you make the current record dirty (On Dirty)
Add your own "find" button to the form (not opening the built in find form), and hide the one on the ribbon.
The hack, work-around we came up with was to write an AutoIt script which can watch for when the Find dialog gains focus and save the record if it has changed.
We didn't want to distribute the script separately from the database, so the the script was added to a database table as a Blob. The database's AutoExec macro runs some VBA code that pulls the script out of the Blob table and starts the script.
When the script detects that the Find dialog has focus, the script runs a VBA macro in the database. The macro checks to see if the current record is dirty. If dirty, the macro forces a save. Also, the AutoIt script is stopped when the database is closed.
This is all pretty awkward, but it works.