AUTOEXEC Macro - Access 2003/2010 Users (1 Viewer)

[Maxis37]

We have users on both ACCESS 2003/XP and ACCESS 2010/Win7. The database is ACCESS 2003 format.

For the Access2010/Win7 users we want to use the [currentproject].[istrusted] to determine whether or not to show a form to ENABLE MACRO on the Security Bar. Our laptop security makes that happen each time a Access2010/Win7 user opens up the database, and we want to keep it that way. The .istrusted works great.

For the Access2003/XP users .istrusted doesn't work so the AUTOEXEC fails on the .istrusted line. ON ERROR isn't in Access 2003, so we can't use that.

We do a GetAccessVersion() function in VBA and if it equals 11 we know that your an Access2003 user so we run the login() and stopmacro and skip the .istrusted CONDITIONS which works fine.

But, for the ACCESS 2010 users, the GetAccessVersion() in VBA won't execute until AFTER they pick the ENABLE MACRO button and that's to late... Never gets to the .istrusted steps to display the form.

I've tried the DIR function and check for OFFICE14 folder, assuming if OFFICE 14 folder is there you're running Access 2010, works great in Access 2003, doesn't work in Access 2010.

I need a CONDITION in the Autoexec MACRO that I can test to determine if I'm Win7 or XP or Access 2003 or Access 2010 that WORKS IN BOTH ACCESS 2003 and 2010. Either operating system or database version works here because all XP users have Access 2003, and all Win7 users have Access 2010.

I tried to used filesystemobject in the CONDITION line, syscmd(acSysCmdAccessVer)=11 too. Didn't understand the syntax of the filesystermobject, and the syscmd worked great in Access 2003 but not in Access 2010.

Am I missing a Access Reference Library?

Can't believe we're the only ones having this issue, users on both versions of Access. WOULD TRULY appreciate any help. I hope I've been clear.

The CONDITION statement in the AUTOEXEC macro has to work for ACCESS 2003 and 2010 and BEFORE the user selects ENABLE MACRO on the security bar in Access 2010. PLEASE!

 

[CJ_London]

have you tried setting the location of the db in trusted locations? Then the enable maco won't 'fire'

 

[Maxis37]

Corporate IT has decided there will be NO trusted locations...Getting the ENABLE MACRO security bar is no problem...users don't seem to mind... but the .istrusted doesn't work for the Access 2003 users and Access 2003 DB format doesn't have ON ERROR for macros yet. No clue how to test for a system folder or get the OS version or Database version without running vba and that will work on the CONDITION line of the AUTOEXEC Macro before the ENABLE macro is selected huh?

 

[SOS]

The only way I think you'll make this work is to have a frontend for each version. It just isn't going to be possible to mix the two given the security structure being so radically different in 2007 and above from 2003.

 

[Maxis37]

no way to check for file or folder on the CONDITION line of the macro in access 2010 before user sets enable macro on security bar huh? or check for error from invalid .istrusted in access 2003?

 

[CJ_London]

Have you considered converting the macro to VBA - I don't know if it will solve the problem but might give you more control

 

[Maxis37]

access 2010 won't run the vba code before the user selects the ENABLE MACROS.... just so hard to believe this wasn't an easy one for all you experts... i was hoping that this was a no brainer... just hope i clearly defined the issue... can't believe you can't run something from the CONDITION in the macro without using vba to find operating system, access version, or folder exists

 

[Maxis37]

the vba will NOT run BEFORE the user selects ENABLE MACRO button.... we need code that will tell if its a win XP/access2003 user or a WIN 7/access 2010... almost anything (including the vba) works for the XP/access2003 users, but the Win 7/access 2010 users and the whole "trusted site" issue can't run any vba code until after they select the ENABLE MACROS on the Security Warning line when ACCESS first comes up. We're trying for ONE autoexec that will run in both environments, but insure the Win7/access2010 user always selects the ENABLE MACRO (.istrusted).

i think the best answer i've received so far is two separate front-ends with the only difference being what autoexec is saved. the xp/access 2003 users just run code login(), the win7/access2010 users test for .istrusted, an once they select ENABLE MACRO, then they run the login() too.

We're must trying to avoid having the two front-ends, more steps to move something to production, etc. etc.

 

[gemma-the-husky]

can you not use simply

application.version

"11" = A2003
"12" = A2007
"14" = A2010

etc

 

[Maxis37]

i'll try that on monday when i get to work... i'm not sure application.version works in the autoexec macro... i know it does in vba, i'll have think about the ACTION to use in the autoexec macro to do application.version.... hmmmm

 

[boblarson]

i'll try that on monday when i get to work... i'm not sure application.version works in the autoexec macro... i know it does in vba, i'll have think about the ACTION to use in the autoexec macro to do application.version.... hmmmm

I can't remember what it was but I swear that I saw an example one time either at an MVP Summit or MS Development Kitchen event that they demonstrated a way to get that via a macro. But for the life of me I just can't remember but vague shadows about it. So, I may be wrong.

 

[Maxis37]

we're all getting old... i thought i remembered something too, but for the life of me... i'm sure someone has done it BEFORE selecting ENABLE MACRO... slowly but surely.. maybe i'll luck out and someone WILL remember

 

[nanscombe]

I don't know a lot about Access macros but when working with web browsers one can look for the existence, or absence, of version specific functions to determine which version you have.

Another thought. What about Digitally signed code?

About digital signatures

A digital signature on a file or Visual Basic for Applications (VBA) project is like a wax seal on an envelope — it confirms that the file originated from the entity who signed it and that the code in the file has not been altered by anyone else. In High or Medium security, a file signed by a trusted entity will be opened without any security warnings.

Show trust by adding a digital signature


Macro security levels

Up to, and including, High level security you can automatically trust particular authors.

Signed macros

The source of the macro and the status of the signature determine how signed macros are handled.

A trusted source. Signature is valid.

Macros are automatically enabled, and the file is opened.

 

[nanscombe]

A straight-forward mdb gives a Security Warning and stops the macro.

A (SelfCert.exe - the free MS version of certification for testing) signed mdb, from a Trusted Publisher, runs to completion without the Security Warning.

 

[Maxis37]

i've got some homework to do... thanks for the hints