Black form after maximizing application back from minimized state

[Hello1]

Suggestions for a better title are welcome.

The environment: server is running Windows Server 2012 R2 and the front end application is located on it, as is the backend databate, mostly SQL Server databases.
Office is 2007.
Client machine is running Windows 10. The client is connecting through RDP to the server and using the application there.

The problem is when the client minimizes the app (actually minimizing works fine) and then when the client maximizes the app back the current form turns black for a few seconds. Sometimes it happens only for a second and it's even difficult to notice but then other times it can hold the black form for even half a minute and turn the application into "not responding".
The form does have a picture as a background but I tried it without it, it didn't seem to help much. I also use conditional formatting to color the control on focus, didn't try to disable it yet.

Anyone had any similar issues?
Thanks

 

[Gasman]

Does it happen on another computer?

 

[Hello1]

As told to me it happened on 2 at pretty similar time, the third one was working fine.
There are like 15 to 20 users all together

 

[Hello1]

The reason of the black screen seems to be related to the number of records. When I open a form in a "single form view" which has like 40k records after bringing back the app from minimized state to maximized the black screen appears for a few seconds but only if I'm on the last record or or somewhere in the middle and up. If I'm on the first record no problems appear, same goes for filtering the form to show only one record.
So my workaround for now is filtering the record needed, never showing them all...

 

[The_Doc_Man]

OK, there is the possibility that you are doing excessive computation at the time, so the image rendering software takes a moment. I.e. the black screen is what you see before Windows renders whatever screen you SHOULD be seeing.

You are using RDP to run Access so the server is doing all of the work. But my thought is to ask this question: Do each of the RDP users have a private copy of the FE in a user-unique folder even though they are all running from the same server? Because if they are not using private copies, you are definitely going to run into serious lock contention. Sharing the FE file is (a) asking for corruption and (b) inviting lock contention. (And the two go hand-in-hand.) The odds of lock contention grow as the factorial of the number of simultaneous users in the case you describe. If you know factorials, you know that 4 users is something like 12 times more likely to have a lock collision than 2 users.

 

[CJ_London]

Having forms with 40,000 records is not a good design. Without any details of your app for a single form I would expect to return just one record, for a continuous form perhaps 20 or 30. Use criteria rather than filters to limit the numbers.

 

[The_Doc_Man]

With 40K records and a shared FE, I'm surprised this even runs without crashing and corrupting the DB.

 

[Hello1]

Do each of the RDP users have a private copy of the FE in a user-unique folder even though they are all running from the same server?

If I understood it right, your question is if every of the users accesses a copy of the FE just made for them? No, they all use the same FE .accde file, they all access that one same file.
I did encounter problems with temporary tables but managed to solve it by creating a temporary table for every user by adding their RDP username to the tmp table name, so each of them would have their own tmp tables. However, I'm aware that this isn't quite the best solution because every of those tables is a part of the FE, instead I'm thinking to make a tmp database for tables like those to not bloat the FE but right now I'm time limited to optimise that all..

Your suggestion is to make a copy of the FE for every user? I was thinking of that in the past but wasn't quite sure how to deal when I have to publish a new version, I would need to overwrite all the .accde's with the new one but there's probably an easy way to do it.

Having forms with 40,000 records is not a good design.

Quite aware but it's an older design. I did work a bit on it, now I have a continuous form with all the customers listed and few unbound fields added for search. I added an event on the double click of the customers ID to open that single form with 40k records but only to filter that one customer which speeds things up. The way I open the form now is "DoCmd.OpenForm DocName, , , LinkCriteria", now this still has all the records underneath but just filters that particular one and it seems fine, regarding speed. However, I was thinking to completely change the record source of the form on open, just to have that one record. Would it make much of a difference? I would need to do quite few changes because I call that form from quite some places.

 

[CJ_London]

they all use the same FE .accde file, they all access that one same file.

That is a recipe for disaster. In a multi user environment, every user should have their own copy of the FE - you don't see users sharing the same copy of Excel, Word, Edge, whatever. And if one user opens an excel or word file, other users trying to open the same file can only open as a copy, there is a reason for that.

Your suggestion is to make a copy of the FE for every user? I was thinking of that in the past but wasn't quite sure how to deal when I have to publish a new version, I would need to overwrite all the .accde's with the new one but there's probably an easy way to do it.

There are plenty of threads on this subject on this and other forums. Here is an example which you can see in the Similar Threads section at the bottom of this thread

just to have that one record. Would it make much of a difference?

I would expect it to.

But be aware that the WHERE parameter of the openform is a filter not a criteria

 

[Hello1]

you don't see users sharing the same copy of Excel, Word, Edge, whatever.

Maybe I'm mistaken but I believe they do in this case scenario "Multi-User operating system". For instance let's take excel, the path to the .exe file is always the same "C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE" (Office 2007). Now every RDP user will use that same .exe file just under another user account?
To be honest so far I didn't encounter any major problems with this, users sharing the same FE. I had some with reports where I use tmp tables, the case I described earlier but other than that not really. But I do get the point, every user having their own FE would probably increase the performance of the FE too, and bloat it way less.

 

[CJ_London]

To be honest so far I didn't encounter any major problems with this, users sharing the same FE.

It's your party, up to you. I had a client a few years ago with the same view. It had not been a problem for 2 or 3 years. Then one day it blew up and they lost months of data because they hadn't bothered with backups.

Now every RDP user will use that same .exe file just under another user account?

think you will find they have their own environment and their own copy in their own C drive. Simple test - put a file on your C drive - can the other users see it?

 

[Hello1]

I appreciate the suggestions and will surely consider implementing the same, as soon as I find spare time. I did check the "similar threads" section and found some interesting ways of doing it.

think you will find they have their own environment and their own copy in their own C drive. Simple test - put a file on your C drive - can the other users see it?

I did try it quickly, I have put a txt file on the C drive from the administrator account and then used one of the client PCs to connect to the server with RDP, the txt file was there. I was able to rename the file but not edit the content of it.