Urgent Help

[vicsalt]

For no reason my Access forms are showing blank as in no cells or sub form on any forms in the database, however if i go into design mode the cells and subforum reappear - Please help

 

[vicsalt]

I noticed it only on linked tables , any form associated with a table that isnt linked as in within the database works fine , i have 30 tables in various backend locations , was working 100% fine 2 hrs ago and the databases are years old

 

[The_Doc_Man]

Your form header and footer both appear and look normal. However, the detail section seems to be missing. Are you sure there are records corresponding to the detail section? I.e. is the .RecordSource pointing to a populated table? This might occur if your form disallows inserting new records, which is a form setting from the .Allowxxxx group of settings.

 

[The_Doc_Man]

Your post #2 and my post #3 came up at about the same time. Have you had a recent update that might have affected your connection that is used by the linked tables?

Are the tables "native Access" i.e. .MDB or .ACCDB files, or are they on something like SQL Server, ORACLE, MySQL, or another ODBC-based SQL database engine?

 

[mike60smart]

For no reason my Access forms are showing blank as in no cells or sub form on any forms in the database, however if i go into design mode the cells and subforum reappear - Please help View attachment 118698View attachment 118699

Hi
Are you able to upload a copy of the database with no confidential data?

 

[vicsalt]

Issues - Back end data for what ever reason was read only, we also had a PC logged into the back end. Once IT remotely kicked everyone out and reset permissions to read & write all was good

 

[Mike Krailo]

That still doesn't make sense why a read only backend would make the forms dissapear. Wait, that's right. Just opening access causes changes to occur internally. Forgot about that.

 

[The_Doc_Man]

Issues - Back end data for what ever reason was read only, we also had a PC logged into the back end. Once IT remotely kicked everyone out and reset permissions to read & write all was good

That symptom suggests a permissions problem OR that the PC that was logged in was opened in Exclusive mode. If there were no other symptoms, I would say "PC opened back-end in Exclusive mode" as the cause of other accesses being read-only. However, it could be a permissions problem if someone opened the .LDB or .LACCDB file exclusively. When Access cannot open the .Lxx file at all AND it is in use, one of the "evasions" is to open the locked file in read-only mode.

Verify that the back end has these two permission setups.
1. The backend file itself allows MODIFY permission to those who want to use it.
2. The folder holding the backend file ALSO allows MODIFY permission to those who want to use it.

Note that setting permissions for "READ,WRITE" is not always enough, particularly for the folder. Instead of READ and WRITE, set MODIFY (as a generic setting), which implies about a dozen fine-grained permissions including the ability to look at file attributes, create and delete files (in the folder), and a couple of others. There are over 20 find-grained permissions and the READ, WRITE, MODIFY, FULL CONTROL settings imply a subset of those over 20 permissions. MODIFY is the one you want. It's like a "permissions macro" in that it conveys more than one component setting.

Then open the backend file, and on the ribbon go to Options >> Client Settings >> Advanced and be sure that it is set for "shared" not "exclusive." You mentioned "backend" which implies a split DB. Be sure that everyone's front end is in trusted location, which means playing around with the Trust Center a little bit. If everyone has a private front-end file, they have FULL CONTROL over that file (from the file permissions viewpoint) so the only other thing to consider is that Windows Trust Center gets picky and can override permissions. So the user's My Documents area is USUALLY one of the trusted locations. Probably wouldn't hurt to do the earlier-mentioned check for shared vs. exclusive to assure the front-end is opened in shared mode as well.

Your earlier problem could ALSO be caused by permissions or by interactions with exclusive-opened DBs. Something else clicked on re-reading your earlier notes.

i have 30 tables in various backend locations

Oh, is THAT ever dangerous!! You have put the ability to open the DB in multiple baskets, but if these are statically linked tables and even ONE of the back-end systems is down, you might be unable to open the DB at all. Dynamically-linked DBs don't necessarily have that particular problem if they also have a way to know that a particular table isn't available.

If everyone is sharing a copy of a single front-end that points to multiple back-ends, that implies you are multiplying file locking all over the place in a way that is probably impeding network efficiency. That is because Windows uses something called Distributed Lock Management. In essence, each file has a file-lock on it ON THE MACHINE THAT HOSTS THE FILE. That machine is the lock manager for that file. If you have multiple users, each talking to multiple back-end files on multiple machines, you have a network matrix of connections that CANNOT be fast.

As long as a back-end capacity issue is not the reason for multiple back ends, you do better (performance-wise) for all tables to be in a single back-end. ALSO, with multiple back-ends, you run into the problem that you cannot define relationships between two tables if they don't reside in the same back-end file. That is because the relationships are stored in the back-end and one back-end doesn't have a method of knowing about another back-end.