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.
Related
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 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.
I have an Access 2010 database A.mdb with a list of tables, one of which is a linked table, linked from another Access database B.mdb on the same server. These databases are on a development machine xxx.xxx.xxx.xxx, which is mapped on my computer as R://, and they are afterwards published online on a yyy.yyy.yyy.yyy server.
If I want to work on the database locally, I need to change the link to the table. But if I change it via filesystem (using the "Linked Table Manager"), the link becomes R://.... and when I look at the ASP page that requests those data, it is broken because the path is wrong. Also, if I change the link locally, it won't work on the online server.
Is there a way to change the link "programmatically"? That is, without using the Linked Table Manager?
I searched for an answer, but I am not that expert, I just understood that I have to write a "Module"? "Macro"?
Table links can be UNC paths. For example, say I have a linked table pointing to a database on \\192.168.1.2\Public\ which is mapped to drive P:. If I launch the VBA editor (Alt+F11), open the Immediate Window (Ctrl+G) and type...
?CurrentDB.TableDefs("remoteTable").Connect
...it will return...
;DATABASE=P:\B.accdb
...because I pointed to drive P: when I created the link.
Now if I create and run the VBA function...
Function linkToUnc()
Dim cdb As DAO.Database
Set cdb = CurrentDb
cdb.TableDefs("remoteTable").Connect = ";DATABASE=\\192.168.1.2\Public\B.accdb"
cdb.TableDefs("remoteTable").RefreshLink
Set cdb = Nothing
End Function
...the link is now a UNC path.
By the way, you can create UNC links in the Linked Table Manager if you browse to "Network", "machine name", "share name", but that will give you the machine name (in my case \\PICO\Public\B.accdb).
you can right click a linked table and select Linked table Manager. Select the linked table you want to work on and tic the checkbox bellow the window which says Always prompt for new location and click the OK button.
You will be asked for the new location. Browse and select the file and click OK.
I like to set up a File DSN on a shared folder accessible with read-access to our entire network and then use a linked table manager to the UNC path. To do this, I use the linked table manager and set up a file DSN on my desktop. I then copy and move the DSN file to the shared UNC directory. Then, I go into Access and delete the linked Table and recreate the linked table. To do this, after deleting the linked table, I do the following:
I click on ODBC Database-->Link to the data source by creating a linked table-->OK.
Click the File Data Source Tab in the Select Data Source Window. At the bottom of the dialogue box, you will see "DSN Name:" followed by a text box and a New Button. You will enter the entire UNC path AND filename into that text box (so this is pointing to the file you copied out to the UNC path). For example, I enter, \ATD-SERVER1\AccessShare\ContactsApp.accdb.dsn. Then click OK.
Assuming you have access permissions to server you are linking to, the Link Tables dialogue box will be displayed and you can then select your linked tables from there! Microsoft couldn't make this any less intuitive if they tried.
I have a 2010 Access Database that I split for so multiple users can use the database at the same time. However, now I can't add data to the front-end through tables, queries, anything. When I go to the back-end it says it's read only and I can't add data or modify design there either, and yes I have proper permissions to view everything. I even tried setting the permissions to Everyone with Full access but it still doesn't work. Any ideas?
When you open the back end db file, Access must be able to create a lock file, or update the lock file if one already exists. When neither happens, the db file will be opened read-only.
That requirement applies when you open the back end db file directly in an Access session. It also applies when you open the back end indirectly from your front end database.
The lock file uses the same base name as your db file, but a different file name extension: .ldb for an MDB db; or .laccdb for an ACCDB db.
Make sure your users have permission to create and delete files in the folder where the back end db file is located. Alternatively, you could just give them modify permission for the lock file once it has been created.
If the problem is not a lock file issue, open one of your linked tables in datasheet view from the front end and see whether you can make changes (add and delete rows, and update values in existing rows). If the linked tables are treated as read-only, delete the links and recreate them. Make sure to inform Access which field or combination of fields to use as a primary key. In the absence of that information, Access will link the tables read-only.
If the linked tables are not read-only, inspect your forms' record sources and other properties. Some queries can still be read-only even though their source tables are editable. And the Data tab of a form's property sheet includes properties such as Allow Additions, Allow Deletions, and Add Edits ... which influence the types of changes which can be made through that form.
Finally, make sure all front end users have default open mode set as shared. If any user's open mode is set as exclusive, all later users can only open read-only.
I have a front-end Access 2007 database connecting to MySql tables using MySQL ODBC connector.
The problem is that a form linked to a table will not refresh its data if the data are changed by another user on the network or if the data was changed by a pop-up form.
If I create a VBA code which detects the change and then refresh the form or requery, then the form which shows many records in a table like format, will jump to its top, and some users will lose the sight of the record which is relevant to them and will have to scroll down to find it again which is not always easy.
Previously, when I was using only Access tables on the network, records would be updated on all access forms if data would change, and the forms would not scroll back to the top...
Is ti possible to make Access form autamaticaly refresh its row if data changed on MySql?
One possible solution is if I could get the form to scroll to the exacly same position after the refresh, but not sure if this can be done...
Check the ODBC refresh interval in your Access application. The default value appears to be 1500 seconds. Perhaps a lower value will allow your form to display its updated contents without code intervention.
Office button -> Access Options -> Advanced, then find ODBC refresh interval near the end of that section of options.
Newer Versions of Office
File -> Options -> Client Settings -> Scroll down to Advanced -> Change ODBC refresh Interval (Sec)
Also, since you have created code to detect data changes on the server, then refresh the forms in response, you could set a bookmark for the form, refresh, and then return to the bookmarked form row.
Recordset.Bookmark Property (DAO)
Update: Changing the form's Recordset Type to Dynaset was the key to resolving this one.
Your first question "Is ti possible to make Access form autamaticaly refresh its row if data changed on MySql?" is clearly answerable: No.
When Access has populated your form, the representation of data in your form becomes totally independent of the record with the same primary key in the database - MySQL has no knowledge, that you are interested in any changes, so it will not inform Access (in fact: there isn't a mechanism to do so)
Concerning the scroll question: In Access 2000 this was possible by activating the record, which would scroll it into view. I suspect it may be similar with Access 2007