Solved Temp Form in VB Editor

[silentwolf]

Hi guys,

just wondering why I have temp Forms in my VB Edito?

And more how can I get rid of them again?

Have not found anything on the net or here.

Hope someone can give me a hint.,

Cheers

Albert

 

[CJ_London]

Have you tried decompile > compact >recompile?

also check for missing and/or unused libraries

 

[arnelgp]

can you create a New db and import all objects (except the temp form) to your new db.

 

[silentwolf]

Hi,

yes I did compact and recompile but does not get rid of it.
If i right click and show object it opens up but I can not delet it anywhere.
Found also a post here regarding this matter not sure if I link it correctly

https://www.access-programmers.co.uk/forums/threads/how-to-delete-tmpclp-files.237902/#post-1213632

tried the code arnelgp provided but unfortunatelly it does not solve the issue..

also check for missing and/or unused libraries

Nothing missing either..

do I need to start all over again if I can't get rid of it?

Don't think it is to good to have those ghosts hanging in the app

 

[silentwolf]

can you create a New db and import all objects (except the temp form) to your new db.

well everything is possible I guess but there are now about 30 odd tables and lots of code ..cry...

 

[arnelgp]

even if there are lots of table, forms, codes...
i'm sure you will have time to pick the right objects (forms, tables, reports, modules, etc) and start the clean up
process.

 

[Mike Krailo]

It doesn't matter if there are a hundred tables or not, you simply use the select all option for all objects in the database during the import. It is real easy to do. This will fix the problem if you import all objects to a new database.

These tmp objects usually appear on a non split database that is being shared by multiple users on a network or wireless connection. At least that is what I have seen happen to my clients.

 

[silentwolf]

Ok thanks guys.

I will do that than.

Thanks for your help and clarifiying

Cheers

 

[isladogs]

No need to import objects to a new database. Another approach is described here:

Remove deleted objects

This article explains how to remove 'legacy' deleted objects from the read only MSysObjects system table if you have problems.

www.isladogs.co.uk

 

[Mike Krailo]

Nice article on the subject isladogs and I always thought that importing the objects was the only way to get rid of those objects as well. It is still a simple method to import all objects into a new database in most cases, but apparently it does take a little longer when the database has as many objects as your sample does. I like that you provided that sample so I can play around with it and test the methods.

 

[silentwolf]

Lol to late gg

But thanks for the article I will look into it!

your comment on
DoCmd.DeleteObject acForm, "~TMPCLP21541"

worked in my case so something learned at least )




Cheers

 

[isladogs]

I wrote the article linked above to document all the steps I took to fix a whole series of object errors in a very large FE database.

For that database, transferring all objects to a blank database took ages & didn't fix all the errors so I looked for other approaches.
With regard to ~TMPCLP objects, these are created automatically when an object is deleted but should be removed when the database is closed or compacted. However, if the database is terminated abnormally (e.g. due to a crash or forced closedown), these objects can be left behind.

Removal of e.g. a form object ~TMPCLP21541 (in order of simplicity) is:
a) DoCmd.DeleteObject acForm, "~TMPCLP21541" ... but this doesn't always work
b) Create new form object with same name - it is automatically deleted
c) Run the DeleteTmpClpObjects procedure supplied with my article
d) Import all objects into new blank database

 

[silentwolf]

Hi thanks so much, this is very interesting.

With Docmd delete ObjectName I was able to first of delete those.
So it was not that major for my end .
However I guess it happend when I deleted a subform maybe there was still somthing closed properly.

But once they are deleted it would be save to keep using that database file?

 

[isladogs]

Sorry but I'm not quite clear what you are asking.
If you want to know whether its safe to continue using the file before / after deleting ~TMPCLP objects, then the answer is Yes

I suggest you compact the database after removing the objects

 

[silentwolf]

Yes that was my question.

I did or do it in regulare bases and when closing the file.

Thanks!

 

[isladogs]

Suggest you disable the compact on close option. It can be a cause of corruption

 

[silentwolf]

Suggest you disable the compact on close option. It can be a cause of corruption

Oh ok.. and it can not happen wenn you manually do it?

 

[Mike Krailo]

It's usually recommended to back everything up first, then do C&R. That way you avoid corruption and can return to your working version.

 

[silentwolf]

Ok Thanks for the advice!
I will keep that in mind done in fact it other way around do save the "compate" Version of the DB.
But good to know that it can get corrupt by doing so.

Cheers

 

[isladogs]

Any compact operation can occasionally fail so backups are indeed a good idea.
The risk with compact on close is much greater as a user could close Access whilst compacting is underway.

The safest method is to compact when the database is closed, either from Explorer or using code from another database