Access 2003 Runtime is driving me mad !

[Vambo]

Having rewritten half of my app to accomodate the Runtime's failings I seem
to have come across another problem when running an Append query which fails
each time but works just fine in a full Access environment.

Is there a limit on the number of records the Runtime can handle (I am
trying to append approx 89000 records to an existing, empty table) ? Both
tables involved have the same characteristics and as I said the query works
ok on my development machine.

Is there a web page detailing the Runtime's limitations that you know of ?

Thanks

V

 

[Rick Brandt]

Having rewritten half of my app to accomodate the Runtime's failings
I seem to have come across another problem when running an Append
query which fails each time but works just fine in a full Access
environment.

Is there a limit on the number of records the Runtime can handle (I am
trying to append approx 89000 records to an existing, empty table) ?
Both tables involved have the same characteristics and as I said the
query works ok on my development machine.

Is there a web page detailing the Runtime's limitations that you know
of ?

Thanks

V

I know of no limitations to the Runtime environment that are outside of the GUI
interface. It IS the exact same access executable.

How exactly does the query fail?

 

[Vambo]

Hi Rick, I just get the standard Runtime error msgbox. I am calling the query
thus:

DoCmd.SetWarnings False
DoCmd.OpenQuery "UpdateFullGL"
DoCmd.SetWarnings True

Could it be that Openquery isn't allowed in the Runtime ?

Thanks

V

 

[Rick Brandt]

Hi Rick, I just get the standard Runtime error msgbox. I am calling
the query thus:

DoCmd.SetWarnings False
DoCmd.OpenQuery "UpdateFullGL"
DoCmd.SetWarnings True

Could it be that Openquery isn't allowed in the Runtime ?

A runtime app should always have robust error handling. What you have there is
not going to tell you what the problem is. Change to...

On Error GoTo ErrHandler

CurrentDB.Execute "UpdateFullGL", dbFailOnError

Egress:
Exit Sub

ErrHandler:
MsgBox "Error: " & Err.Number & VbCrLf & Err.Description
Resume Egress
End Sub

That should at least give you a full message indicating what the error is.

 

[Vambo]

Thanks Rick, I'll give it a go.

V

A runtime app should always have robust error handling. What you have there is
not going to tell you what the problem is. Change to...

On Error GoTo ErrHandler

CurrentDB.Execute "UpdateFullGL", dbFailOnError

Egress:
Exit Sub

ErrHandler:
MsgBox "Error: " & Err.Number & VbCrLf & Err.Description
Resume Egress
End Sub

That should at least give you a full message indicating what the error is.

 

[Vambo]

Hi Rick, sorry that didn't help, first of all I get the Action Failed dialog
(the code is called from a macro) and then the bog standard Runtime error
dialog.

Any other ideas please ?

V

 

[Paul Overway]

Aside from AutoExec and AutoKeys, you really shouldn't be using any macros
in a runtime application. Error handling is EXTREMELY important in a
runtime application and macros do not provide for it. I suspect you have a
problem with a reference, but without proper error handling it is difficult
to say for sure.

 

[Rick Brandt]

Hi Rick, sorry that didn't help, first of all I get the Action Failed
dialog (the code is called from a macro) and then the bog standard
Runtime error dialog.

Any other ideas please ?

Lose the macros. They don't belong in a runtime app period.

 

[Vambo]

Rick, Love to. Unfortunately this is part of the Autoexec which sets up the
users reference data.

V

 

[Lynn Trapp]

Anything you have in an Autoexec macro can be run from a form module or a
standard module that is called in the open event of your startup form. As
both Rick and Paul have advised, you need to move away from the macro in a
runtime environment.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[Vambo]

Hi Lynn, thanks for that. I am already working on coding all of the Autoexec
bits and pieces to the main form (On activate).

V

 

[Lynn Trapp]

The Activate event will work but, if you navigate to and from the main form
throughout a session, then your code will fire every time. If that's what
you want, then that would be the appropriate place for it. However, if it's
something you only want to fire once, you should probably put it in the Open
event of the main form.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[Vambo]

Hi Lynn, the main form is only opened once, all others are opened as 'pop-ups'.

V

 

[Lynn Trapp]

Then you should be good to go.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html