@Peter101793 You can always indicate who you are addressing by using the @ sign and username.This reply was intended for Isladogs. Sorry that my inexperience in using this forum meant that my reply was mis-posted.
My last UA response to you wasn't prompted by the fact that your code didn't work for me. I wrote because I didn't believe comments like "Why waste everyone's time unnecessarily? " and "Help us to help you!" were in any way appropriate. In almost 1000 UA posts, which included a number of silly mistakes on my part, I have never been on the end of words like you used. In some forums a moderator would censure what you wrote.
I have carried out further tests on your code, modified by my hidden field. It works robustly. However there are two problems with your attempts to meet my requirement to open a passworded .accdr. The first is it will not work without full Access. The second, which I believe rules out your solution completely, is that the starter DB requires the password of the .accde to be included in viewable code because it is included in a non-encrypted database. The elegance of the original solution gets round this by including all passwords in the passworded .accdr from which all code is stripped. So I'm afraid it seems to me we're back to square one on this.
Whilst it does not get highlighted like other forums, the meaning is clear.
Please use # icon on toolbar when posting code snippets.
Cross Posting: https://www.excelguru.ca/content.php?184
Debugging Access: https://www.youtube.com/results?sear...bug+access+vba
@Peter101793
I explained the reasons for my comments in the thread at UA. I see no benefit in repeating them again here
I've already explained that .accde files can be locked down with the same restrictions as .accdr. In fact, additional restrictions can be imposed.
For that reason, I've not spent time trying to get this to work with .accdr.
Incorrect. The target db password can (indeed should) be encrypted in the code.the starter DB requires the password of the .accde to be included in viewable code because it is included in a non-encrypted database
In any case, the code I supplied also works from a source ACCDE file so the code used wouldn't be accessible anyway.
Anyway, I have no wish to spend any more time trying to assist when it appears that you don't want my help.
In my opinion, the code I supplied should do everything you need as long as you work with .accdb/.accde files for the target db.
I'm going to drop out of this thread now.
EDIT: I've just seen your final comment in post #10. I appreciate that
Fair enough Colin. Despite a few misunderstandings, I believe the code you posted in UA will meet my requirements, modified with the hidden field/Application.UserControl property. So thank you. A solution for use in the runtime environment, as you said in a much earlier post, may remain out of reach in Office 365.@Peter101793
I explained the reasons for my comments in the thread at UA. I see no benefit in repeating them again here
I've already explained that .accde files can be locked down with the same restrictions as .accdr. In fact, additional restrictions can be imposed.
For that reason, I've not spent time trying to get this to work with .accdr.
Incorrect. The target db password can (indeed should) be encrypted in the code.
In any case, the code I supplied also works from a source ACCDE file so the code used wouldn't be accessible anyway.
Anyway, I have no wish to spend any more time trying to assist when it appears that you don't want my help.
In my opinion, the code I supplied should do everything you need as long as you work with .accdb/.accde files for the target db.
I'm going to drop out of this thread now.
EDIT: I've just seen your final comment in post #10. I appreciate that
It is my intention to post here and on UA a simple application showing the final code solution. Thanks to you and all who have participated on this thread.
Peter.
add folder "c:\scratchdir" to your Trusted location.
thankssssssssssss![]()