Ha ha, Thanks!
Maybe I did because (as I wrote in one of my first posts in this forum) I speak VBA better than English.
In actually, google translate and wordreference are very useful assistants.
So, by taking part in this forum, I exercise my English as well.
Hi Tom,
Here is the accdb version of my utility, feel free to explore it.
Cheers,
Vlad
John @ #14:
You keep on impressing me!!! Just like moke123 already stated, I also got fooled (in a good way) by you. I surely what you were, e.g., either American or British living in Greece.
As I have opened quite a few threads lately, I always feel that "my problem is already solved" the moment I see that you contributed to the thread. Experts like you (particularly w/ such positive personality) are always, ALWAYS a pleasure to communicate with.
Hats up to you!
Cheers,
Tom
Vlad -- I also would like to thank you for posting the cleanup utility. Once downloaded, I added 3 Ptr Safe lines to the arguments lines. Once I opened it, I tried to dabble with it before kicking off my work routine. When clicking on "double-click to select database to be cleaned" (see attached) nothing happens though.
Hi Tom,
Sorry, it was designed for 32bit and the common dialog has been removed in 64bit. I will update it to work in both versions but until then just copy and paste the full path to the file.
Cheers,
moke123 -- good morning. You (and others) helped me previously w/ solving a process. I posted a related *yet slightly different* post at the following URL.
https://www.accessforums.net/showthr...914#post474914
Given your previous background on the process, I was wondering if you had some ideas for the new process (same concept but for different table types).
moke123:
Earlier in March, you've helped me out tremendously by creating a routine that deletes LK tables that are not needed. I hope you remember.
This process has been working great thus far. However, at this time, I am hoping you would be willing to provide me little bit more assistance with slightly tweaking the process. If you prefer, I will open up a new thread. Just let me know what works best for you.
Process Recap for Creating LKs:
===============================
- I have 5 source tables (containing prefix = "tbl_"). **For demo purposes only**, each table contains only 1 record. (Actual # of records = 70k).
- I open up form "F01_MainMenu" -- this forms contains 2 listboxes.
- In the left listbox, I click on the 3 options (top to bottom).
- Upon having clicked 3rd option ("Create & Load..."), a message box indicates that *207* LK tables were created. This count can be validated by clicking on query "FieldNamesQ". So far so good!
Process Recap for Removing LKs that are Not Needed:
================================================== =
- Again, upon having click on "Create LKs...", I ended up with 207 LK tables.
- Reality is, however, that I only need a subset of those LKs (instead of one for every field).
- Thus, with the help of another expert (moke123) in March, I ended up extending the functionality which would delete any "non-LOV" (i.e., LKs that are not needed).
- So, via the right listbox, I would click on the 1st menu item "Delete LK Tables...".
- The delete tables routine is linked to table [delete_tables_nonLOV].
- Specifically, all LK tables where [LOV] = FALSE will be deleted from the database. Thus far, this process also worked fine!
Current Issue:
==============
- Up until yesterday, I actually had 2 of the source tables split up via multiple files.
- For reasons beyond this post, I decided to merge all fields of the multiple source tables (from the same organization) into a single table. Thus, I have 5 source tables (vs. 11 tables).
- As part of this field merging, however, my DELETE LK tables does NO longer work as it did originally. And I can't figure out why.
- Specially, if you open query "Count_Of_LK_Tables_Generated", the count of LK tables = 96 (that's the count **AFTER** I ran the DELETE function).
- However, when you open query "Count_Of_LK_Tables_To_Keep", the record count = 92.
- So, for some reason 4 LK tables (LK_DAFW, LK_EQUIPMENT, LK_EVENT, LK_FIRST_LINE_SUPERVISOR_NAME) still remain in the DB even though there Boolean flag = FALSE in table [delete_tables_nonLOV].
Here's What I Need Some Help With:
==================================
Do you see the reason as to why the 4 LKs (LK_DAFW, LK_EQUIPMENT, LK_EVENT, LK_FIRST_LINE_SUPERVISOR_NAME) are NOT deleted given their Boolean flag = FALSE. I just don't seem to find the issue as to why only a subset of the LOV = FALSE tables would be deleted (vs. all).
Again, if you prefer me to open up a new post, I will gladly do so.
Thank you for your help in advance.
Cheers,
Tom
moke123 -- never mind the question. I think I solved it by linked the DELETE_TABLE to query FieldNamesQ. This now only creates the LK that I need.
If this helped, please click the star * at the bottom left and add to my reputation- Thanks
No worries... 'totally understand.
Cheers,
Tom