Access 2007 Runtime problems

[Dave C]

I thought I was ready to start deploying an application I've been working on
the for past year -- think again! It won't run under the Access 2007 Runtime.

I'm using the newly released Access 2007 Runtime version 2.

The first problem was with having function names specified as an event
property. (For example =HandleButton(1) as the event, instead of [Event
Procedure] and a procedure in the module MyButton_Click() that calls
HandleButton 1. What upset me most about this is that it was a form Access
created for me (the switchboard) that I had to fix.

The second one -- the one that really has me worried -- has to do with sub
forms. It's effecting a large number of forms in my project. The sub forms
don't show. Works perfect in the full version of Access, and perfect with
the /Runtime switch on the development machine with Access installed.
Doesn't work on a machine that only has the Runtime.

I can't find any documentation on this bug. There's lots of talk about a
problem with subforms if the subform is pulling data from a remote data
source, but that's not the case here. Both form and subform are pulling data
from local tables. Both are bound forms.

I'm sure something's I've done that's setting these forms apart from normal,
because I can't believe MS would have missed something as basic as a
form/subform relationship when creating the runtime and its version 2.

Could it possibly be that the form is called with acDialog? Some property
in the subform's original definition that's ignored in the full version, but
that the runtime trips over?

Desperate for any suggestions at this point.

 

[guzarva16]

"Dave C" <[email protected]> เขียนเป็นข้อความ
news:[email protected]...

 

[Dave C]

I was barking up the wrong tree. It wasn't the form/subform that was doing
it, it was a problem with the query used in the subform. When I tried
running the subform directly, I got the error message which helped me track
down the problem.

It didn't like this as one of the fields in the query:

Warning:iif((PointsAvailable>0 and UseYearEnds < date()) or (AvailableToBank

0 and BankingDeadline < date())," ! ",iif((PointsAvailable>0 and

UseYearEnds < dateadd("d",-60,date())) or (AvailableToBank>0 and
BankingDeadline < dateadd("d",-60,date())),"!",""))

I use this field, along with conditional formatting, to display a red
exclamation point if a deadline's been missed, or a yellow exclamation point
if a deadline is near.

The error message was something regarding a function being illegal in an
expression. I'm not sure if it was the dateadd(), the iif(), or the date()
that it didn't like.

I moved the statement into a function and replaced the field with
warning:FindUseYearWarning(PointsAvailable,UseYearEnds,AvailableToBank,BankingDeadline) and now it works.

I also notice that when I move it into the function, Access strips off the
paranthesis from the date() function. Perhaps this is it?

Now I'm off to find the functions it doesn't like in my other queries...

 

[Dave C]

It's the IIf that causes the problems.

 

[Dave C]

It's actually not just IIF, it's just about any native Access function used
as part of a query. Nz, Format, IIF... the list goes on.

I've taken to writing local version of each of these, which resolves the
problem. But it's a pain in the neck!

Public Function MyNz( byval poValue as variant, byval poAlternate as
variant) as variant
MyNz = Nz(poValue,poAlternate)
End Function

How's that for efficient! It solves the problem, though. I hope there's a
patch to the runtime on it's way soon.