function doesn't return value - SOMETIMES!

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a function defined in a header which reads matching records in its
subform and updates fields in the the header recordset. (I know this is
non-normal, but the fields are needed for display and performance reasons.)

MOST of the time this routine works fine, but occasionally it doesn't.
Until Friday I was never able to catch it misperforming, but then I caught it
with its pants down. The line

GetOrderDtlSummary("Dispatch", Nz(Me.RecordKey), Nz(tEstQty), _
Nz(tActQty), Nz(tDollars)) & ""

calls the function

Public Function GetOrderDtlSummary(DispatchOrStanding As String, _
OrderKey As Long, tDtlEstQty As Double, tDtlActQty As Double,
tDollars As Double) As String

which reads the detail records and returns tEstQty, tAcrQty and tDollars,
which I then use to update the header.

On Friday I could watch this in debug mode, see the variables calculated
properly in the called function, and then RETURNED TO THE CALLING FUNCTION AS
0. MOST of the time, this has worked fine.

What might be causing this bizarre sporadic behavior?

Kevin
 
Kevin,
I think I have seen something like that before when declaring a numerical
variable as an integer only to find out later that it was not large enough
and having to redeclare it as a long to handle the larger numbers. I had
discovered this when a function returned zero. But if I am understanding you
correctly. You are saying that you followed the code all the way through to
the very end of the Public Function GetOrderDtlSummary() and at the end of
the function GetOrderDtlSummary = the correct results and when the calling
Sub received them all it received was a big fat zero? Hmmmm.... Well the only
thing I can see is that you are declaring 3 of your numerical values as
doubles... are you sure that datatype is large enough to handle the data? My
guess would be that when this code is not functioning it would be because of
the declared Double data type not being large enough to handle the data. And
when it does work correctly that would be because this data type is
sufficient in size to handle the data it contains. Also Note: I have read
that you do not gain anything by declaring a double versus long so maybe you
should try using the long data type... Can you reproduce the circumstances of
Friday with the data type changed to a long and see what happens? Or maybe
use the currency datatype? If that does not solve it can you place more of
your code on here for review?
Take Care & God Bless ~ SPARKER ~
 
Sparker -

'Far as I know, Long is an integer and doesn't handle decimals; Double can
handle much larger numbers, and DOES handle decimals. So I don't think
that's it.

Thanks anyway.
 
Hello Kevin,

It seems the calling stack has some issues. This could occur if the
database is corrupted or if there is issues inside the function called
which overwrites the stack by mistake. Did you perform sth special in the
function? If not, I suggest that you create a new database, and import the
objects from the original one to test.

Also, pelase make sure you have installed the latest Jet driver.

More related information:

209137 ACC2000: How to Troubleshoot/Repair a Damaged Jet 4.0 Database
http://support.microsoft.com/?id=209137

247771 ACC2000: How to Recover Data from a Damaged (Corrupted) Table
http://support.microsoft.com/?id=247771

Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

=====================================================


This posting is provided "AS IS" with no warranties, and confers no rights.




--------------------
| Thread-Topic: function doesn't return value - SOMETIMES!
| thread-index: AcV06yzrdtoK6vATSa+xjdX7XvIMvw==
| X-WBNR-Posting-Host: 67.86.86.237
| From: "=?Utf-8?B?S2V2aW4gV2l0dHk=?=" <[email protected]>
| References: <[email protected]>
<[email protected]>
| Subject: RE: function doesn't return value - SOMETIMES!
| Date: Sun, 19 Jun 2005 09:23:06 -0700
| Lines: 62
| Message-ID: <[email protected]>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.access.modulesdaovba
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.access.modulesdaovba:29903
| X-Tomcat-NG: microsoft.public.access.modulesdaovba
|
| Sparker -
|
| 'Far as I know, Long is an integer and doesn't handle decimals; Double
can
| handle much larger numbers, and DOES handle decimals. So I don't think
| that's it.
|
| Thanks anyway.
|
| "sparker" wrote:
|
| > Kevin,
| > I think I have seen something like that before when declaring a
numerical
| > variable as an integer only to find out later that it was not large
enough
| > and having to redeclare it as a long to handle the larger numbers. I
had
| > discovered this when a function returned zero. But if I am
understanding you
| > correctly. You are saying that you followed the code all the way
through to
| > the very end of the Public Function GetOrderDtlSummary() and at the end
of
| > the function GetOrderDtlSummary = the correct results and when the
calling
| > Sub received them all it received was a big fat zero? Hmmmm.... Well
the only
| > thing I can see is that you are declaring 3 of your numerical values as
| > doubles... are you sure that datatype is large enough to handle the
data? My
| > guess would be that when this code is not functioning it would be
because of
| > the declared Double data type not being large enough to handle the
data. And
| > when it does work correctly that would be because this data type is
| > sufficient in size to handle the data it contains. Also Note: I have
read
| > that you do not gain anything by declaring a double versus long so
maybe you
| > should try using the long data type... Can you reproduce the
circumstances of
| > Friday with the data type changed to a long and see what happens? Or
maybe
| > use the currency datatype? If that does not solve it can you place more
of
| > your code on here for review?
| > Take Care & God Bless ~ SPARKER ~
| >
| >
| > "Kevin Witty" wrote:
| >
| > > I have a function defined in a header which reads matching records in
its
| > > subform and updates fields in the the header recordset. (I know this
is
| > > non-normal, but the fields are needed for display and performance
reasons.)
| > >
| > > MOST of the time this routine works fine, but occasionally it
doesn't.
| > > Until Friday I was never able to catch it misperforming, but then I
caught it
| > > with its pants down. The line
| > >
| > > GetOrderDtlSummary("Dispatch", Nz(Me.RecordKey), Nz(tEstQty), _
| > > Nz(tActQty), Nz(tDollars)) & ""
| > >
| > > calls the function
| > >
| > > Public Function GetOrderDtlSummary(DispatchOrStanding As String, _
| > > OrderKey As Long, tDtlEstQty As Double, tDtlActQty As Double,
| > > tDollars As Double) As String
| > >
| > > which reads the detail records and returns tEstQty, tAcrQty and
tDollars,
| > > which I then use to update the header.
| > >
| > > On Friday I could watch this in debug mode, see the variables
calculated
| > > properly in the called function, and then RETURNED TO THE CALLING
FUNCTION AS
| > > 0. MOST of the time, this has worked fine.
| > >
| > > What might be causing this bizarre sporadic behavior?
| > >
| > > Kevin
|
 
Thanks, Peter. At least that tells me I'm not nuts.

I don't know what "sth special" is. ??? All the function does is to read
records in a query which match a supplied key and return totals on certain
fields.

I assume the calling stack problem would be in the front end, not the back?
I do rebuild the front end pretty regularly, but I'll do it again and see if
the problem goes away. It has been a while since the back end has been
compact/repaired, but I just installed a routine which does a nightly jetcomp
on it. Maybe that will fix the problem.

Thanks,

Kevin
 
Hello Kevin,

For "sth special" I means if you call API or some third components/DLLs in
this function which may bring problems. It is a good idea.

300216 HOW TO: Keep a Jet 4.0 Database in Top Working Condition
http://support.microsoft.com/?id=300216

Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

=====================================================


This posting is provided "AS IS" with no warranties, and confers no rights.




--------------------
| Thread-Topic: function doesn't return value - SOMETIMES!
| thread-index: AcV1kxVgS92ocKxWQmGa+EAIfx3PWg==
| X-WBNR-Posting-Host: 67.86.86.237
| From: "=?Utf-8?B?S2V2aW4gV2l0dHk=?=" <[email protected]>
| References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
| Subject: RE: function doesn't return value - SOMETIMES!
| Date: Mon, 20 Jun 2005 05:25:02 -0700
| Lines: 169
| Message-ID: <[email protected]>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.access.modulesdaovba
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.access.modulesdaovba:29943
| X-Tomcat-NG: microsoft.public.access.modulesdaovba
|
| Thanks, Peter. At least that tells me I'm not nuts.
|
| I don't know what "sth special" is. ??? All the function does is to
read
| records in a query which match a supplied key and return totals on
certain
| fields.
|
| I assume the calling stack problem would be in the front end, not the
back?
| I do rebuild the front end pretty regularly, but I'll do it again and see
if
| the problem goes away. It has been a while since the back end has been
| compact/repaired, but I just installed a routine which does a nightly
jetcomp
| on it. Maybe that will fix the problem.
|
| Thanks,
|
| Kevin
|
| "Peter Yang [MSFT]" wrote:
|
| > Hello Kevin,
| >
| > It seems the calling stack has some issues. This could occur if the
| > database is corrupted or if there is issues inside the function called
| > which overwrites the stack by mistake. Did you perform sth special in
the
| > function? If not, I suggest that you create a new database, and import
the
| > objects from the original one to test.
| >
| > Also, pelase make sure you have installed the latest Jet driver.
| >
| > More related information:
| >
| > 209137 ACC2000: How to Troubleshoot/Repair a Damaged Jet 4.0 Database
| > http://support.microsoft.com/?id=209137
| >
| > 247771 ACC2000: How to Recover Data from a Damaged (Corrupted) Table
| > http://support.microsoft.com/?id=247771
| >
| > Regards,
| >
| > Peter Yang
| > MCSE2000/2003, MCSA, MCDBA
| > Microsoft Online Partner Support
| >
| > When responding to posts, please "Reply to Group" via your newsreader
so
| > that others may learn and benefit from your issue.
| >
| > =====================================================
| >
| >
| > This posting is provided "AS IS" with no warranties, and confers no
rights.
| >
| >
| >
| >
| > --------------------
| > | Thread-Topic: function doesn't return value - SOMETIMES!
| > | thread-index: AcV06yzrdtoK6vATSa+xjdX7XvIMvw==
| > | X-WBNR-Posting-Host: 67.86.86.237
| > | From: "=?Utf-8?B?S2V2aW4gV2l0dHk=?=" <[email protected]>
| > | References: <[email protected]>
| > <[email protected]>
| > | Subject: RE: function doesn't return value - SOMETIMES!
| > | Date: Sun, 19 Jun 2005 09:23:06 -0700
| > | Lines: 62
| > | Message-ID: <[email protected]>
| > | MIME-Version: 1.0
| > | Content-Type: text/plain;
| > | charset="Utf-8"
| > | Content-Transfer-Encoding: 7bit
| > | X-Newsreader: Microsoft CDO for Windows 2000
| > | Content-Class: urn:content-classes:message
| > | Importance: normal
| > | Priority: normal
| > | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| > | Newsgroups: microsoft.public.access.modulesdaovba
| > | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| > | Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
| > | Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.access.modulesdaovba:29903
| > | X-Tomcat-NG: microsoft.public.access.modulesdaovba
| > |
| > | Sparker -
| > |
| > | 'Far as I know, Long is an integer and doesn't handle decimals;
Double
| > can
| > | handle much larger numbers, and DOES handle decimals. So I don't
think
| > | that's it.
| > |
| > | Thanks anyway.
| > |
| > | "sparker" wrote:
| > |
| > | > Kevin,
| > | > I think I have seen something like that before when declaring a
| > numerical
| > | > variable as an integer only to find out later that it was not large
| > enough
| > | > and having to redeclare it as a long to handle the larger numbers.
I
| > had
| > | > discovered this when a function returned zero. But if I am
| > understanding you
| > | > correctly. You are saying that you followed the code all the way
| > through to
| > | > the very end of the Public Function GetOrderDtlSummary() and at the
end
| > of
| > | > the function GetOrderDtlSummary = the correct results and when the
| > calling
| > | > Sub received them all it received was a big fat zero? Hmmmm....
Well
| > the only
| > | > thing I can see is that you are declaring 3 of your numerical
values as
| > | > doubles... are you sure that datatype is large enough to handle the
| > data? My
| > | > guess would be that when this code is not functioning it would be
| > because of
| > | > the declared Double data type not being large enough to handle the
| > data. And
| > | > when it does work correctly that would be because this data type is
| > | > sufficient in size to handle the data it contains. Also Note: I
have
| > read
| > | > that you do not gain anything by declaring a double versus long so
| > maybe you
| > | > should try using the long data type... Can you reproduce the
| > circumstances of
| > | > Friday with the data type changed to a long and see what happens?
Or
| > maybe
| > | > use the currency datatype? If that does not solve it can you place
more
| > of
| > | > your code on here for review?
| > | > Take Care & God Bless ~ SPARKER ~
| > | >
| > | >
| > | > "Kevin Witty" wrote:
| > | >
| > | > > I have a function defined in a header which reads matching
records in
| > its
| > | > > subform and updates fields in the the header recordset. (I know
this
| > is
| > | > > non-normal, but the fields are needed for display and performance
| > reasons.)
| > | > >
| > | > > MOST of the time this routine works fine, but occasionally it
| > doesn't.
| > | > > Until Friday I was never able to catch it misperforming, but then
I
| > caught it
| > | > > with its pants down. The line
| > | > >
| > | > > GetOrderDtlSummary("Dispatch", Nz(Me.RecordKey), Nz(tEstQty), _
| > | > > Nz(tActQty), Nz(tDollars)) & ""
| > | > >
| > | > > calls the function
| > | > >
| > | > > Public Function GetOrderDtlSummary(DispatchOrStanding As String, _
| > | > > OrderKey As Long, tDtlEstQty As Double, tDtlActQty As
Double,
| > | > > tDollars As Double) As String
| > | > >
| > | > > which reads the detail records and returns tEstQty, tAcrQty and
| > tDollars,
| > | > > which I then use to update the header.
| > | > >
| > | > > On Friday I could watch this in debug mode, see the variables
| > calculated
| > | > > properly in the called function, and then RETURNED TO THE CALLING
| > FUNCTION AS
| > | > > 0. MOST of the time, this has worked fine.
| > | > >
| > | > > What might be causing this bizarre sporadic behavior?
| > | > >
| > | > > Kevin
| > |
| >
| >
|
 
Back
Top