Access Runtime Crashes On DMAX

[CharlesWhiteman]

I've debugged my Db to the point where I know that at the following line of code Access Runtime Halts on a runtime error.

I'd be gald of any advise?

My Db works perfectly on my PC and full version of Access

strRadAcctID = DMax("[RadAcctID]", "RadAcct", "[UserName] = Forms.FrmPrimaryData.txtMacAddress")

 

[CharlesWhiteman]

I've noticed that, having installed the runtime version on my developing computer, that I dont get the runtime crashes.

The system which its being deployed on is Server 2008 64-Bit.

 

[boblarson]

1. are you using an ACCDE/MDE file in the runtime? It will not crash if you are using a compiled version. If you use the mdb/accdb file then it will.

2. you need to use ! after the word Forms and the Form reference should be OUTSIDE of the quotes:


strRadAcctID = DMax("[RadAcctID]", "RadAcct", "[UserName] = " & Chr(34) & Forms!FrmPrimaryData.txtMacAddress & Chr(34))

The CHR(34) is a double quote which you can either use it, a single quote, or triple double quotes. I like Chr(34) because it is easy to see what is going on.

You need it for any text fields, of which UserName would be one.

 

[CharlesWhiteman]

Hi Bob, having just followed your greatfully received advice I copied your altered string and then debug compiled and then packaged.

Installed onto the 64-bit machine and same thing happend. Works fine on my developper machine in access runtime which is 32-bit.

The access runtime 2007 on the 64-bit machine is access runtime 32-bit. I cant seem to find a 64-bit version of the 2007 runtime.

 

[boblarson]

There currently is no 64 bit runtime available.

 

[CharlesWhiteman]

I'm thinking that there may lie the key? Maybe the 32 bit references dont work on the 64bit opsys? any thoughts?

 

[boblarson]

Are you using any API calls or ActiveX components? Other than those, if you aren't using any it should run just fine.

 

[CharlesWhiteman]

Ok, I've managed to trap the error and on the server for some reason the OBBD connection fails also though the system dsn tests absolutely fine. hmm..

 

[CharlesWhiteman]

now I've found that the ODBC links setup on my developer machine did not carry though. Also, ODBC in 64-Bit Server 2008 doesnt give the choice of a system DSN.

 

[boblarson]

If you are using 32 bit Office you should be using 32 bit ODBC, but you have to go to the 32 bit ODBC driver area to build a DSN.

You would need to start up the ODBC manager from:
C:\WINDOWS\SysWOW64\odbcad32.exe

and build your DSN from there.

 

[CharlesWhiteman]

I Luv'ya Bob!! Top Banana

That fixed it.

 

[boblarson]

Glad to hear

 

[CharlesWhiteman]

Just thought I'd feed this back for info and to ensure I'm not keeping issues to myself!

I've noticed that the ODBC linked tables seem to have to have the link setup on the actual machine. And then also per user logon too. Each installed instance of the front end (although I havent split just yet) also has to be individually ODBC linked. Clearly a bit of a pain.

 

[CharlesWhiteman]

Would i be better setting the DSN as a funtion in VBa?

 

[boblarson]

Not quite true. You can link and it does not have to refer to an individual machine. But you do need to have a DSN with the same name on each machine (unless you use a FILE DSN which actually can be easier because then you don't need to create a DSN on each user's machine). You can also use DSNLess connections which, if you search for DSNLess and Doug Steele you will find some good Google material.

As for the password, you can click SAVE PASSWORD as you link the tables and then nobody else will need to do it. However, if you have certain things restricted, using SQL Server Authentication and not using Windows Authentication then you would need to have each user sign in.

 

[CharlesWhiteman]

Many thanks for the info. I will investigate and post back.

 

[CharlesWhiteman]

Step 1) Recreate the linked table but based on a File DSN. for a multi-user approach and/or multi machine a file DSN is definately a step forward.

 

[gemma-the-husky]

well, in your statement the where bit is not correct - so it is not surprising you get an error. But this will also error in a full envrionment, I think.

"[UserName] = Forms.FrmPrimaryData.txtMacAddress"