Open a pasworded runtime database

[Welshgasman]

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.

@Peter101793 You can always indicate who you are addressing by using the @ sign and username.


Whilst it does not get highlighted like other forums, the meaning is clear.

[jojowhite]

I've tested your code with the db attached (including sample .accdr located in c:\scratchdir. Password 03LeIl1). Unfortunately my tests pop-up the password box when the .accdr opens. Am I doing something wrong?

when i extract it, it says the archive is corrupt.

[isladogs]

@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.

the starter DB requires the password of the .accde to be included in viewable code because it is included in a non-encrypted database

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

[Peter101793]

@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

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.
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.

[jojowhite]

add folder "c:\scratchdir" to your Trusted location.

[sharawee]

thankssssssssssss

[Peter101793]

I now have a solution which meets all my requirements except that which should not require full Access. Posting code as a zip file is not possible in UA and although this is possible in the Access-programmers forum, I cannot get it to work for an 11mb file. I have therefore set out details at this link.


The posts above include details of frustration between myself and Colin (Isladogs) where his experience of the code he offered wasn't mine. Specifically, closing the second database at the same time as the first, which made me wonder if I'd adequately explained my requirements. Although I found a workaround (hidden field), it wasn't until I installed Colin's code on another PC, using the same Office 365 version, that I found it worked as he described. Returning to the PC where the code failed and re-installing Office 365 resulted in correct code performance without my workaround. So, apologies to Isladogs. But this experience raises the question of the hidden fragility of Access in Office 365 which is an everchanging codebase because of regular online background updates. I never had this problem when I provided users with a defined version (2010/2013) of Access runtime.

I have made similar posts to the other forums where I shared my problem.

[pbaldy]

Post 22 was moderated, I'm posting to trigger email notifications.