Creating new form from existing form

You compact the database after you export the form to text and delete the original. Then you import the text form and compact again.

Do all the forms and queries that are on the form with the issue at one time. That way you only have to compact twice instead of between each object. By compacting, you are attempting to avoid having the bad p-code reattach to the objects when you reimport them. Even better though is probably a decompile since C&R doesn't always remove all p-code but the decompile is intended to specifically remove p-code to solve this problem.
 
Hi Pat,

Yes, I tried C&R, in fact I use that function regularly. I have also decompiled/recompiled the database to a new, balnk database several times.

I've uninstalled Windows Office 2010 and reinstalled and ensured all updates are in place.

Every time I think I've cured the problem, it pops up again. Sometimes, just opening the db and selecting an item from a combo on the main screen will cause the combos to stop working, even though the buttons for other functions continue working...

I am at a loss as to what to try next but I'm moving towards submitting the db to Access World for comment, although it will not work in some areas, it should be enough to experience the problem...or not, as the case may be.

Do you still think posting it is a possibility?

DaveE
 
If you post we can verify it is not an issue with your Access application. If we cannot replicate the issue then the problem is with your Installation of Access.
 
The database is too large for the server - it says. So I will, tomorrow, cut down the db to just the mainform, subforms, and tables which should provide something to look at and analyse.

DaveE
 
The more trim down the better. Just enough to show the issue.
 
What is the max size allowed for the server?
The cut-down db is around 3.7MB.

DaveE
 
How large is the database? Is it split?
I have reduced the db to a main form with 2 subforms and a few small pop-up forms to show functionality.
2 tables, a few queries, and a fair bit of VBA code.
The db is not split.
Would compressing the db be worthwhile?

DaveE
 
OK, the db has been compressed down to almost nothing...
It should get through
Before compressing it exhibited the same problem, as described earlier.

I have cut it down, removed a lot of forms/reports/tables/code. I have disabled some of the controls on the MainForm to avoid error messages for missings objects. MainForm is the primary form.

I look forward to comments about the problem (but not necessarily the design).

Thanks for any forthcoming help

DaveE
 

Attachments

We can serve you better if you actually answer questions:(

ALWAYS compact the database when you remove objects. Otherwise, the db will not be reduced in size.
 
I'm sorry if I missed a question somewhere along the line. Your last 2 questions were answered though; size and whether it was split...perhaps there was a time delay in you receiving the responses.

I have compacted the db so many times I've lost count. It was compacted after being reduced and, prior to that, it was decompiled/recompiled as recommended by your good self in the way you suggested.

The db, after zipping went from 3.7MB to 837KB.

DaveE
 
I'm sorry if I missed a question somewhere along the line
I think the question is now that we can see the database, can you walk us through how to recreate and see the issue. Use actual form and control names.
 
There are only 2 issues that I can find.

The first involves the opening of the form in View mode and then selecting Design View by right-mouse-clicking the form's top bar or anywhere on the open space on the form. In some, but not all cases, the db will close leaving the database locking file open in the folder and preventing re-opening until the Microsoft Access (32bit) task is removed from the Background Tasks section of Task Manager.

The second issue is that doing the same thing - selecting Design View, can result in the form remaining open but All combos frozen (no action), although the Buttons along the top of the MainOptions screen remain operational. Again, the locking file is still open and the database requires the same Task Manager operation to re-open and work.

There are no specific controls that cause the problems. Just the action of switching the views of the MainOptions form will cause the problem. I am still unsure if this is an Access or Windows problem.

The mouse is wireless and the drivers up-to-date and doesn't misbehave with any other program.
 
Make sure I got the steps correct.
1. Open the MainOptions switch to design view using right mouse. Db may close
2. Open the MainOptions and switch to design view using right mouse. Form may remain open but combos locked.

Pretty sure the problem is in your API calls in the form. I did the above numerous times and cannot recreate the issue. However before starting I commented the loadcursor function out because I needed to make it 64 bit compatible. Unless you need it get rid of it.
 
Last edited:
That is exactly what the problem is. Open in design view and do not move the mouse over the subform that causes the finger pointing mouse (no call to the API). Close the form no problem. Do it again and make the finger pointing mouse come up (call the API function) and it crashes/locks. Fails every time. 100% repeatable as far as I can tell.
If you really need this API function for the fancy pointer I would reach out to @sonic8; he is probably the API guru on this site. @isladogs is also pretty good. I cannot help with that, not my area.
 
Last edited:
You said - "The database is too large for the server - it says."
So I asked TWO relevant questions.
1. How big is the database? NOT how big will the database be after you have removed a bunch of stuff. That is not relevant to the error.
2. Is the database split into a FE and BE and you never answered that one either. A database that is not split is always larger than it needs to be and is also prone to corruption.

Neither may be relevant but when you are getting errors about the db being too large, they certainly need to be asked.

The problem seems to be the API so perhaps someone can offer a different alternative.
 
You said - "The database is too large for the server - it says."
So I asked TWO relevant questions.
1. How big is the database? NOT how big will the database be after you have removed a bunch of stuff. That is not relevant to the error.
2. Is the database split into a FE and BE and you never answered that one either. A database that is not split is always larger than it needs to be and is also prone to corruption.

Neither may be relevant but when you are getting errors about the db being too large, they certainly need to be asked.

The problem seems to be the API so perhaps someone can offer a different alternative.
Hi Pat,

Looking back, chronologically, through this thread I see that I had already supplied the answers prior to your questions. Maybe that was why you didn't see them. Thanks for your help.

DaveE
 
i don't see any problem with MainForm?
btw i change it to pop-up (centered).
 

Attachments

i don't see any problem with MainForm?
btw i change it to pop-up (centered
The problems is on MainOptions. That was my fault I wrote MainView. I corrected it.
Buttons along the top of the MainOptions screen remain operational.

1. Open the MainView.
2. There is a plantlist subform on the left. Take your mouse and move it in the subform. This brings up the finger pointer. 👉
3. Switch to design view
4. If it does not crash. Close the db and it will be locked.
 
Although I got rid of the setcursor and loadcursor API calls for testing, I still crashed, although less often. I would try removing all API code and see if that helps. This version posted by @arnelgp for me is even more unstable then previous versions. This crashes when I simply close the form. So I really think the culprit is API.
 

Users who are viewing this thread

Back
Top Bottom