Help with trouble autoincrementing non-ABC 
Author Message
 Help with trouble autoincrementing non-ABC

Hello everyone,

I would expect the following code to return a 1 to Alerts.RecordID when
beginning with an empty table, but it is not.  It is giving me a very large
negative number.  This is a simple table with one autoincrementing key.

      CLEAR(Alerts.Record,1)
      SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
      PREVIOUS(Alerts)
?     ASSERT(NOT(ERRORCODE())
      Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

Can someone spot what I am doing wrong?

TIA - Randy



Sun, 15 May 2005 06:34:30 GMT  
 Help with trouble autoincrementing non-ABC
This happens here as well so

if  Alerts.RecordID < 1 then  Alerts.RecordID = 1 .

    Elli

On Tue, 26 Nov 2002 15:34:30 -0700, "RJS International"

Quote:

>Hello everyone,

>I would expect the following code to return a 1 to Alerts.RecordID when
>beginning with an empty table, but it is not.  It is giving me a very large
>negative number.  This is a simple table with one autoincrementing key.

>      CLEAR(Alerts.Record,1)
>      SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
>      PREVIOUS(Alerts)
>?     ASSERT(NOT(ERRORCODE())
>      Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

>Can someone spot what I am doing wrong?

>TIA - Randy



Sun, 15 May 2005 07:01:22 GMT  
 Help with trouble autoincrementing non-ABC
Hi Randy,

On Tue, 26 Nov 2002 15:34:30 -0700, "RJS International"

Quote:

>Can someone spot what I am doing wrong?

Use:

 Clear(Alerts.Record)
 Set(Alerts.RecordIDKey)
 Previous(Alerts)
 If ErrorCode()
   I = 1
 Else
   I = Alerts.RecordID+1
 End

Or just use:

 Access:Alerts.PrimeAutoInc

to do this for you automagically:)

Best regards,

Arnr Baldvinsson
Icetips Software        
San Antonio, Texas, USA
www.icetips.com

ICQ:  113314380

Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm



Sun, 15 May 2005 07:31:54 GMT  
 Help with trouble autoincrementing non-ABC
Eli and Arnor,

Thanks for your responses.

We are incrementing outside of ABC up at the ErrorClass so we have to stay
away from the useful tools for this particular table--it is the error log.
And we have long used our own flavor of auto-incrementing very similar to
what Arnor outlined, but we saw this on the Clarion Foundry and thought it
might save a couple of lines.  Then we just got stubborn and wanted to know
why it was failing.

What is confusing me is that the previous clearly fails but the
Alerts.RecordID does not get the "1," even though the choose operates
properly???  I will move on now that you guys have said it is happening to
you too, but do you know why?  It must be my misunderstanding of the Clear()
command but I thought I understood it.

Thanks again - Randy


Quote:
> Hello everyone,

> I would expect the following code to return a 1 to Alerts.RecordID when
> beginning with an empty table, but it is not.  It is giving me a very
large
> negative number.  This is a simple table with one autoincrementing key.

>       CLEAR(Alerts.Record,1)
>       SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
>       PREVIOUS(Alerts)
> ?     ASSERT(NOT(ERRORCODE())
>       Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

> Can someone spot what I am doing wrong?

> TIA - Randy



Sun, 15 May 2005 07:50:10 GMT  
 Help with trouble autoincrementing non-ABC


Quote:
> Access:Alerts.PrimeAutoInc

He's talking about legacy (".... Non-ABC" in the subject)

Is there a way to invoke that method from legacy?

--
Mark Riffey
Granite Bear
http://www.granitebear.com



Sun, 15 May 2005 00:53:14 GMT  
 Help with trouble autoincrementing non-ABC
Elli,

I just noticed that your name has 2 Ls in it and I wanted to apologize for
misspelling it in my earlier response.  I have glasses, but I really need to
see an eye doctor so I can get proper eye glasses.  Anyway, I will be more
careful next time.

Thanks - Randy


Quote:
> Eli and Arnor,

> Thanks for your responses.

> We are incrementing outside of ABC up at the ErrorClass so we have to stay
> away from the useful tools for this particular table--it is the error log.
> And we have long used our own flavor of auto-incrementing very similar to
> what Arnor outlined, but we saw this on the Clarion Foundry and thought it
> might save a couple of lines.  Then we just got stubborn and wanted to
know
> why it was failing.

> What is confusing me is that the previous clearly fails but the
> Alerts.RecordID does not get the "1," even though the choose operates
> properly???  I will move on now that you guys have said it is happening to
> you too, but do you know why?  It must be my misunderstanding of the
Clear()
> command but I thought I understood it.

> Thanks again - Randy



> > Hello everyone,

> > I would expect the following code to return a 1 to Alerts.RecordID when
> > beginning with an empty table, but it is not.  It is giving me a very
> large
> > negative number.  This is a simple table with one autoincrementing key.

> >       CLEAR(Alerts.Record,1)
> >       SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
> >       PREVIOUS(Alerts)
> > ?     ASSERT(NOT(ERRORCODE())
> >       Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

> > Can someone spot what I am doing wrong?

> > TIA - Randy



Sun, 15 May 2005 09:10:50 GMT  
 Help with trouble autoincrementing non-ABC
Hi Mark,



Quote:
>He's talking about legacy (".... Non-ABC" in the subject)

>Is there a way to invoke that method from legacy?

Not unless you use most of the ABC classes as far as I can see, in
which case your app is already gone to ABC<g>

The first code I posted works in Legacy

Best regards,

Arnr Baldvinsson
Icetips Software        
San Antonio, Texas, USA
www.icetips.com

ICQ:  113314380

Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm



Sun, 15 May 2005 13:30:54 GMT  
 Help with trouble autoincrementing non-ABC
Hi Randy,

On Tue, 26 Nov 2002 16:50:10 -0700, "RJS International"

Quote:

>And we have long used our own flavor of auto-incrementing very similar to
>what Arnor outlined, but we saw this on the Clarion Foundry and thought it
>might save a couple of lines.  Then we just got stubborn and wanted to know
>why it was failing.

There are three things that I can see right away.

1.  IF you need to autoincrement a field in a compound key, you MUST
use Set(Key,Key) otherwise you should use Set(Key).  In the first case
you would have code like this:

Clear(MYF:Record,1)
MYF:Field1 = 1
Set(MYF:Key1,MYF:Key1)
Previous(MyFile)
If ErrorCode() Or MYF:Field1 <> 1
  I = 1
Else
  I = MYF:Field2 + 1
End
MYF:Field1 = 1
MYF:Field2 = I

2.  There is a potential problem in the code that you posted:

      PREVIOUS(Alerts)
?     ASSERT(NOT(ERRORCODE())
      Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

The ErrorCode() in Choose() may NOT be checking the errorcode after
Previous, but after ASSERT().  

You MUST remember that a lot of functions in Clarion reset the
ErrorCode() values.  So in this case:

      PREVIOUS(Alerts)
      ErrorCode = ErrorCode()
?     ASSERT(NOT(ERRORCODE)
      Alerts.RecordID = CHOOSE(ERRORCODE,1,Alerts.RecordID + 1)

would be safe, wheras the original may not be safe.  I do not trust
any internal function not to mess with the values of Error() and
ErrorCode() so I usually do things like this in routines, and start
with

 Data
ErrorCode  Long
Error      CString(256)
 Code

and assign these immediately after a function where I have to know the
error state.  

3.  Take a look at this line:

      Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

From the help:  "When the condition evaluates as true, then CHOOSE
returns the first value parameter."

Does Choose() think that ErrorCode() is True because it returns a
non-zero value?  I'm not so sure (haven't tested) because I see code
like this:

CHOOSE(ERRORCODE() = 0, Level:Benign, Level:Notify)

all over the ABC classes and in a lot of other code.  When I use
Choose() I make absolutely 100% certain that Choose() knows what I'm
referring to.  So in your case, I would rewrite this as:

      Alerts.RecordID = CHOOSE(ERRORCODE()<>0,1,Alerts.RecordID + 1)

or with my variables:

      Alerts.RecordID = CHOOSE(ERRORCODE<>0,1,Alerts.RecordID + 1)

This makes certain that the first value is returned if an error is
returned after Previous().

Once you have checked these three items out, I'm sure that your code
will work as expected:)

Best regards,

Arnr Baldvinsson
Icetips Software        
San Antonio, Texas, USA
www.icetips.com

ICQ:  113314380

Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm



Sun, 15 May 2005 13:46:03 GMT  
 Help with trouble autoincrementing non-ABC


Quote:
> Not unless you use most of the ABC classes as far as I can see, in
> which case your app is already gone to ABC<g>

I thought maybe you had made some top secret discovery<g>

Quote:

> The first code I posted works in Legacy

Yep. Same as the templates, mostly.

--
Mark Riffey
Granite Bear
http://www.granitebear.com



Sun, 15 May 2005 06:53:10 GMT  
 Help with trouble autoincrementing non-ABC
Arnor,

Thanks for staying with this basic of most basic things we have to do in
file management.  Your understanding of the Choose() function was correct
and provided the answer to the confusion.  This works:

      CLEAR(Alerts.Record,1)
      SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
      PREVIOUS(Alerts)
      Alerts.RecordID = CHOOSE(ERRORCODE()<>0,1,Alerts.RecordID + 1)

I had just been trying the ASSERT() out to see how it behaved as well and it
does not really belong there; we expect the Previous() to fail under certain
conditions.

Your point about immediately capturing the errorcode and / or error is also
a good one.  We do that everywhere else, also.  This was just a snippet I
picked up on the Foundry and got stubborn with.  I am glad I did because now
we have shortened a few lines of code and understand the Choose() a little
better.

Thanks again - Randy


Quote:
> Hi Randy,

> On Tue, 26 Nov 2002 16:50:10 -0700, "RJS International"

> >And we have long used our own flavor of auto-incrementing very similar to
> >what Arnor outlined, but we saw this on the Clarion Foundry and thought
it
> >might save a couple of lines.  Then we just got stubborn and wanted to
know
> >why it was failing.

> There are three things that I can see right away.

> 1.  IF you need to autoincrement a field in a compound key, you MUST
> use Set(Key,Key) otherwise you should use Set(Key).  In the first case
> you would have code like this:

> Clear(MYF:Record,1)
> MYF:Field1 = 1
> Set(MYF:Key1,MYF:Key1)
> Previous(MyFile)
> If ErrorCode() Or MYF:Field1 <> 1
>   I = 1
> Else
>   I = MYF:Field2 + 1
> End
> MYF:Field1 = 1
> MYF:Field2 = I

> 2.  There is a potential problem in the code that you posted:

>       PREVIOUS(Alerts)
> ?     ASSERT(NOT(ERRORCODE())
>       Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

> The ErrorCode() in Choose() may NOT be checking the errorcode after
> Previous, but after ASSERT().

> You MUST remember that a lot of functions in Clarion reset the
> ErrorCode() values.  So in this case:

>       PREVIOUS(Alerts)
>       ErrorCode = ErrorCode()
> ?     ASSERT(NOT(ERRORCODE)
>       Alerts.RecordID = CHOOSE(ERRORCODE,1,Alerts.RecordID + 1)

> would be safe, wheras the original may not be safe.  I do not trust
> any internal function not to mess with the values of Error() and
> ErrorCode() so I usually do things like this in routines, and start
> with

>  Data
> ErrorCode  Long
> Error      CString(256)
>  Code

> and assign these immediately after a function where I have to know the
> error state.

> 3.  Take a look at this line:

>       Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

> From the help:  "When the condition evaluates as true, then CHOOSE
> returns the first value parameter."

> Does Choose() think that ErrorCode() is True because it returns a
> non-zero value?  I'm not so sure (haven't tested) because I see code
> like this:

> CHOOSE(ERRORCODE() = 0, Level:Benign, Level:Notify)

> all over the ABC classes and in a lot of other code.  When I use
> Choose() I make absolutely 100% certain that Choose() knows what I'm
> referring to.  So in your case, I would rewrite this as:

>       Alerts.RecordID = CHOOSE(ERRORCODE()<>0,1,Alerts.RecordID + 1)

> or with my variables:

>       Alerts.RecordID = CHOOSE(ERRORCODE<>0,1,Alerts.RecordID + 1)

> This makes certain that the first value is returned if an error is
> returned after Previous().

> Once you have checked these three items out, I'm sure that your code
> will work as expected:)

> Best regards,

> Arnr Baldvinsson
> Icetips Software
> San Antonio, Texas, USA
> www.icetips.com

> ICQ:  113314380

> Subscribe to information from Icetips.com:
> http://www.icetips.com/getnotificationinfo.htm



Mon, 16 May 2005 00:55:53 GMT  
 Help with trouble autoincrementing non-ABC
Hi Randy,

On Wed, 27 Nov 2002 09:55:53 -0700, "RJS International"

Quote:

>Your point about immediately capturing the errorcode and / or error is also
>a good one.  We do that everywhere else, also.  This was just a snippet I
>picked up on the Foundry and got stubborn with.  I am glad I did because now
>we have shortened a few lines of code and understand the Choose() a little
>better.

I'm using Choose() a LOT, but I have run into similar situations so I
make sure that the condition evaluates to true, like ErrorCode()<>0,
ThisVar=1342 or whatever, no fuzzy logic please<g>

Best regards,

Arnr Baldvinsson
Icetips Software        
San Antonio, Texas, USA
www.icetips.com

ICQ:  113314380

Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm



Mon, 16 May 2005 01:22:42 GMT  
 Help with trouble autoincrementing non-ABC
Thought I might better post this for any newbies that might copy this
without thinking about it:

l_RecordID      LONG,AUTO

      CLEAR(Alerts.Record,1)
      SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
      PREVIOUS(Alerts)
      l_RecordID = CHOOSE(ERRORCODE()<>0,1,Alerts.RecordID + 1)
      CLEAR(Alerts.Record)
      Alerts.RecordID        = l_RecordID

It is sloppy to assign the actual table column the results of the Choose()
because it is sloppy not to clear the record structure after the next
auto-incremented number has been obtained.  It is better to define a local
variable to received the new RecordID, then clear the record structure, then
assign the table column to the local variable.

This seems like extra code, but if you have ever added columns to a table
structure after writing such code, you will understand why we do it this
way.

Thanks everyone - Randy


Quote:
> Arnor,

> Thanks for staying with this basic of most basic things we have to do in
> file management.  Your understanding of the Choose() function was correct
> and provided the answer to the confusion.  This works:

>       CLEAR(Alerts.Record,1)
>       SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
>       PREVIOUS(Alerts)
>       Alerts.RecordID = CHOOSE(ERRORCODE()<>0,1,Alerts.RecordID + 1)

> I had just been trying the ASSERT() out to see how it behaved as well and
it
> does not really belong there; we expect the Previous() to fail under
certain
> conditions.

> Your point about immediately capturing the errorcode and / or error is
also
> a good one.  We do that everywhere else, also.  This was just a snippet I
> picked up on the Foundry and got stubborn with.  I am glad I did because
now
> we have shortened a few lines of code and understand the Choose() a little
> better.

> Thanks again - Randy



> > Hi Randy,

> > On Tue, 26 Nov 2002 16:50:10 -0700, "RJS International"

> > >And we have long used our own flavor of auto-incrementing very similar
to
> > >what Arnor outlined, but we saw this on the Clarion Foundry and thought
> it
> > >might save a couple of lines.  Then we just got stubborn and wanted to
> know
> > >why it was failing.

> > There are three things that I can see right away.

> > 1.  IF you need to autoincrement a field in a compound key, you MUST
> > use Set(Key,Key) otherwise you should use Set(Key).  In the first case
> > you would have code like this:

> > Clear(MYF:Record,1)
> > MYF:Field1 = 1
> > Set(MYF:Key1,MYF:Key1)
> > Previous(MyFile)
> > If ErrorCode() Or MYF:Field1 <> 1
> >   I = 1
> > Else
> >   I = MYF:Field2 + 1
> > End
> > MYF:Field1 = 1
> > MYF:Field2 = I

> > 2.  There is a potential problem in the code that you posted:

> >       PREVIOUS(Alerts)
> > ?     ASSERT(NOT(ERRORCODE())
> >       Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

> > The ErrorCode() in Choose() may NOT be checking the errorcode after
> > Previous, but after ASSERT().

> > You MUST remember that a lot of functions in Clarion reset the
> > ErrorCode() values.  So in this case:

> >       PREVIOUS(Alerts)
> >       ErrorCode = ErrorCode()
> > ?     ASSERT(NOT(ERRORCODE)
> >       Alerts.RecordID = CHOOSE(ERRORCODE,1,Alerts.RecordID + 1)

> > would be safe, wheras the original may not be safe.  I do not trust
> > any internal function not to mess with the values of Error() and
> > ErrorCode() so I usually do things like this in routines, and start
> > with

> >  Data
> > ErrorCode  Long
> > Error      CString(256)
> >  Code

> > and assign these immediately after a function where I have to know the
> > error state.

> > 3.  Take a look at this line:

> >       Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

> > From the help:  "When the condition evaluates as true, then CHOOSE
> > returns the first value parameter."

> > Does Choose() think that ErrorCode() is True because it returns a
> > non-zero value?  I'm not so sure (haven't tested) because I see code
> > like this:

> > CHOOSE(ERRORCODE() = 0, Level:Benign, Level:Notify)

> > all over the ABC classes and in a lot of other code.  When I use
> > Choose() I make absolutely 100% certain that Choose() knows what I'm
> > referring to.  So in your case, I would rewrite this as:

> >       Alerts.RecordID = CHOOSE(ERRORCODE()<>0,1,Alerts.RecordID + 1)

> > or with my variables:

> >       Alerts.RecordID = CHOOSE(ERRORCODE<>0,1,Alerts.RecordID + 1)

> > This makes certain that the first value is returned if an error is
> > returned after Previous().

> > Once you have checked these three items out, I'm sure that your code
> > will work as expected:)

> > Best regards,

> > Arnr Baldvinsson
> > Icetips Software
> > San Antonio, Texas, USA
> > www.icetips.com

> > ICQ:  113314380

> > Subscribe to information from Icetips.com:
> > http://www.icetips.com/getnotificationinfo.htm



Mon, 16 May 2005 02:10:00 GMT  
 Help with trouble autoincrementing non-ABC
Dont worry everybody overseas calls  me all sort of names including
girl names like "Ellie may" and , some of my classmates in LA ignored
my Icelandic name alltogether and called me George :-)
I need glassed to , but not going out and getting them is my way of
saying i am not getting older  :-)

        Best regards

        Elli

On Tue, 26 Nov 2002 18:10:50 -0700, "RJS International"

Quote:

>Elli,

>I just noticed that your name has 2 Ls in it and I wanted to apologize for
>misspelling it in my earlier response.  I have glasses, but I really need to
>see an eye doctor so I can get proper eye glasses.  Anyway, I will be more
>careful next time.

>Thanks - Randy



>> Eli and Arnor,

>> Thanks for your responses.

>> We are incrementing outside of ABC up at the ErrorClass so we have to stay
>> away from the useful tools for this particular table--it is the error log.
>> And we have long used our own flavor of auto-incrementing very similar to
>> what Arnor outlined, but we saw this on the Clarion Foundry and thought it
>> might save a couple of lines.  Then we just got stubborn and wanted to
>know
>> why it was failing.

>> What is confusing me is that the previous clearly fails but the
>> Alerts.RecordID does not get the "1," even though the choose operates
>> properly???  I will move on now that you guys have said it is happening to
>> you too, but do you know why?  It must be my misunderstanding of the
>Clear()
>> command but I thought I understood it.

>> Thanks again - Randy



>> > Hello everyone,

>> > I would expect the following code to return a 1 to Alerts.RecordID when
>> > beginning with an empty table, but it is not.  It is giving me a very
>> large
>> > negative number.  This is a simple table with one autoincrementing key.

>> >       CLEAR(Alerts.Record,1)
>> >       SET(Alerts.RecordIDKey,Alerts.RecordIDKey)
>> >       PREVIOUS(Alerts)
>> > ?     ASSERT(NOT(ERRORCODE())
>> >       Alerts.RecordID = CHOOSE(ERRORCODE(),1,Alerts.RecordID + 1)

>> > Can someone spot what I am doing wrong?

>> > TIA - Randy



Mon, 16 May 2005 02:24:04 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. ABC AutoIncrementing outside the templates

2. Wierd problem when calling function ABC as: [ABC] *or* eval ABC

3. C5 abc SECWIN Font Trouble

4. non relational lookup with abc

5. Troubles with BUILD in ABC templates.

6. Troubles with BUILD in ABC templates, persist.

7. File Manager 2 limits And CFW4b (non-ABC)

8. ABC Virtual/Non and Local Embeds

9. getting autoincrementing key to update child field in code

10. C4 - Autoincrementing default values for multi-valued template symbols

11. Autoincrementing a Decimal

12. autoincrementing

 

 
Powered by phpBB® Forum Software