Hi everyone,
At last I believe that I've got to a solution of this problem although I'm
not sure that I understand why the solution works and the original method
doesn't. Hopefully someone out there can tell my why I've been stupid - I
already know I am!
I've tried to make this example as simple and general as possible:
Driving Table: DataTable
Columns: DataNumber, Content (not placed on the form)
Fields: vfDataNumber, vfContent
Content has a pop-up menu based on the variable look-up (Menu_Description IN
Various_Menus) so that the field displays the text value rather than the
idnum that I need stored.
Previously declared variables on form:
vfDataNumber = DataNumber (INTEGER)
and either of the examples shown below...
EEP run on exit from vfContent field:
SET VAR vuContent TEXT = NULL
SELECT Menu_Returned INTO vuContent FROM Various_Menus +
WHERE Menu_Description = .vfContent
UPDATE DataTable SET Content = .vuContent +
WHERE DataNumber = .vfDataNumber
RECALC TABLES
RECALC VARIABLES
RETURN
(For clarity, a quick word on the naming convention:
vfVarName is a field variable,
vuVarName is an update variable,
vfluVarName is a field look-up variable.)
On using the form with the variables below:
This text variable for the field fails:
vfContent = Menu_Description IN Various_Menus WHERE Menu_Returned = Content
(the table column)
In this case the original table data is first displayed correctly and is
updated by the menu. So far, so good. When the EEP runs if the RECALC
VARIABLES command is left in the EEP the Content field reverts to its
original value a few moments later.
If the recalc command is removed then the update works but the variables are
not updated - obviously. Also, if another field runs an EEP that uses RECALC
VARIABLES then the vfContent field reverts to its original value. Then, when
the row is left, the table then gets re-updated with the original value -
not what I wanted!
However, these two variables work:
(INTEGER) vfluContent = Content IN DataTable WHERE DataNumber =
.vfDataNumber
(TEXT) vfContent = Menu_Description IN Various_Menus WHERE
Menu_Returned = .vfluContent
(Using this method the RECALC command is not needed as the form always
displays the correct data anyway.)
Conclusion:
The reason that I asked Razzak to confirm that nothing had been changed in
the RECALC and NEXTROW/[F8] commands should now be obvious - it looked to me
as if RECALC was not updating when using the first method's variable under
some circumstances. However, vfContent definitely was being updated just
before the EEP was run because the table was getting updated. With
confirmation that nothing had changed I had to accept that my method was
wrong somewhere.
Eventually, I tried the second example. This seemed to force R:Base to check
the look-up variable (vfluContent) every time that RECALC VARIABLES was used
thus getting the latest data from the table.
I don't know if something's changed recently to cause this or whether I was
just trying to be too clever to attempt the lookup in one go. Whatever, I'm
happy again!
A couple of "by-the-by's":
I've used TRACE a lot in getting to the bottom of this and one of the things
it does - or rather, doesn't - do is to actively land on the RECALC
commands. In the example above it would go straight from the UPDATE to the
RETURN command. Nothing really wrong with that but it's a bit disconcerting.
The other strange thing that TRACE seems to do is not to display long file
names properly in its error messages. Something to be checked for v7 if it
hasn't already been done.
Thanks to everyone who offered suggestions - they all gave me avenues to
explore in trying to find the solution.
Regards,
Alastair.
----- Original Message -----
From: "A. Razzak Memon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 4:57 AM
Subject: Re: Heads Up - Razzak's Reply
>
> At 10:03 PM 11/19/2002 +0000, Alastair Burr wrote:
> >Razzak,
> >
> >Please could you confirm a couple of things for me?
> >
> >To stop me looking for something that has not changed can you verify that
> >the functioning of:
> >
> >[F7] / [F8]
> >SAVEROW
> >NEXTROW / PREVROW
> >RECALC VARIABLES / TABLES
> >
> >have not been tweaked or changed - even indirectly (obviously, as far as
you
> >know) in any way in the latest beta?
> >
> >I'm _still_ not at all convinced that the problem is in the latest beta
but
> >I haven't found an error on my part either - yet.
> >
> >Thanks & regards,
>
>
> G'day Alastair,
>
> TTBOMK, nothing has been tweaked nor changed - even indirectly!
>
> Enjoy the latest and greatest version of The Glorious R:BASE 2000 (ver
6.5++)!
>
> Let me give you a little hint, Alastair: There are HUNDREDS of
> Developers/Users
> and clients who are running their Mission_Critical_Applications using the
> latest
> and greatest private beta of TGRB2000 (ver 6.5++), Build:1.860xRT03. If
> there were
> such issues, our phones will be ringing constantly and I probably had the
> new build
> released right away! You would have also heard a lot from our respectable
> developers
> on list list who are not only beta testing but managing very complex and
> critical
> applications for their lovely clients, including myself and my wonderful
> clients.
>
> Remember, myself and the talented Dream Team will do anything we can. Yes,
I'm
> very PROUD of our system, our products and the way we take care of our
CURRENT
> and LOYAL R:BASE users. The rest is history!
>
> Very Best Regards,
>
> Razzak.
>
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
================================================
TO SEARCH ARCHIVES:
http://www.mail-archive.com/rbase-l%40sonetmail.com/
