Access Runtime configuration

[Phonik]

Hello all,

I have recently finished developing a Complaints Database for my company and we carried out some testing on machines that use runtime only and guess what? Good old runtime errors!
I aksed the IT department to give me a brand new blank login profile and when I used this, the database worked perfectly under the runtime environment. This tells me that the runtime on users machines that have worked here for some time, something has changed with the way in which runtime works.
What I would like to try and do is for these machines, when the database loads up, to re-install or re-configure Access runtime so it is effectively a clean Runtime slate for want of a better expression.
Does anyone know how I could do this or possibly even offer any assistance in another way. My understanding of runtime is that it has most of the Access capabilities but obviously without design, build, debug functions etc and is purely a 'cloak' to allow the mdb file to be viewed/executed.

Thanks folks.

Gareth

 

[gemma-the-husky]

what errors were you getting? are you using an mdw or the default workgroup?

 

[Phonik]

Hi,

Thanks for your reply. I am not sure what you mean??
The error says "Runtime error and does not give any specific detail. Once I click on OK it throws me out.

Thanks

Gareth

 

[gemma-the-husky]

sorry, silly thought, you won't get error handling

i'm sure you know that if you are using access run-time, normal access error reporting is disabled. therefore you have to do it all yourslef.

in the form causing the error you need a form error event, then you can intercept the error, and at least do a

msgbox("error: " & err.number & " Desc: " & err.description) to identify the error and determine how you handle it.

I would be surprised if it is a defective run-time, its more likely an unhandled code error.

if you are launching the app by referring to a particular mdw workgroup, then maybe its something to do with your users privileges within that workgroup.

 

[Phonik]

Ok great Thanks!!

So will I need to put error handling on ALL of my functions? (Oh dear god!)

Thanks

Gareth

 

[gemma-the-husky]

not really, not in functions you know are foolproof. its just that something is making your app go wrong, and an unhandled error is crashing the runtime. if you put an error handler in the form error event, you will at least get some idea of what it is, to enable you to fix it.

its no different to a full access application, giving you an error, and offering the end/debug options. This is exactly the same, but in the runtime it crashes the app. this is concerning, as you may have partially updated records, and so on, and this may cause ongoing problems in the app. You want to avoid getting the end/debug message also, which you do by intercepting these run time errors.

but with a run time app, it could be anything, missing variable, bad data type, null data value, divide by zero, recordset dao errors, query parameter errors, even just cancelling a report open, because there's no data causes an error event that needs handling.

 

[Phonik]

This is really helpful thank you so much!

Gareth