ERROR 65 why when get() works?

[JD Kromkowski]

I don’t understand why I get error 65 trying to use ! operator instead of get() … type(db1record) rCLAIMS integer i sbme1table claims integer iID,iCMNo string sfield,sfield1 e = 0; iCMNo = 0 claims =@ app.CLAIMS appw =@ getappwindowfromwindow(getmenuitemwindow(me)) rCLAIMS =@ appw.form.selectcurrent(claims.firstindex,error = e) // this next line works perfectly fine sfield = rCLAIMS.get(claims.firstfield) // here i am trying to get the exact same thing // I put the if test just to make sure I was spelling // the field name correctly if claims.firstfield.name == “CLMLASTNAM” // this next line throws error 65 – WHY? sfield1 = rCLAIMS!CLMLASTNAM end if

[JD Kromkowski]

Any thoughts on this?

On 03/06/13 5:19 PM, kromkowski wrote:
> I don't understand why I get error 65 trying to use ! operator instead
> of get()
> …
> type(db1record) rCLAIMS
> integer i
> sbme1table claims
> integer iID,iCMNo
> string sfield,sfield1
> e = 0; iCMNo = 0
> claims =@ app.CLAIMS
> appw =@ getappwindowfromwindow(getmenuitemwindow(me))
> rCLAIMS =@ appw.form.selectcurrent(claims.firstindex,error = e)
> // this next line works perfectly fine
> sfield = rCLAIMS.get(claims.firstfield)
>
> // here i am trying to get the exact same thing
> // I put the if test just to make sure I was spelling
> // the field name correctly
> if claims.firstfield.name == "CLMLASTNAM"
> // this next line throws error 65 – WHY?
> sfield1 = rCLAIMS!CLMLASTNAM
> end if

[Jean Vallee]

On 3/11/2013 4:11 PM, kromkowski wrote:
> Any thoughts on this?
>
> On 03/06/13 5:19 PM, kromkowski wrote:
>> I don't understand why I get error 65 trying to use ! operator instead
>> of get()
>> …
>> type(db1record) rCLAIMS
>> integer i
>> sbme1table claims
>> integer iID,iCMNo
>> string sfield,sfield1
>> e = 0; iCMNo = 0
>> claims =@ app.CLAIMS
>> appw =@ getappwindowfromwindow(getmenuitemwindow(me))
>> rCLAIMS =@ appw.form.selectcurrent(claims.firstindex,error = e)
>> // this next line works perfectly fine
>> sfield = rCLAIMS.get(claims.firstfield)
>>
>> // here i am trying to get the exact same thing
>> // I put the if test just to make sure I was spelling
>> // the field name correctly
>> if claims.firstfield.name == "CLMLASTNAM"
>> // this next line throws error 65 – WHY?
>> sfield1 = rCLAIMS!CLMLASTNAM
>> end if
>
>
Nice to know I'm not the only one who has encountered this.

I too get error 65 on occasion when it makes no sense.

I have to use something else to get past so I can keep coding.

Jean Vallee

[Jim Locker]

rCLAIMS is a record object. That object has attributes, methods, and
properties – but none of those are an index, though a pointer to the index
that was used to locate this record is provided.
..
An index is a separate object, again with its own attributes, methods, and
properties – including a pointer to the record object with which is is
associated.
..
These are distinct objects; an index is not a member of a record object.
..
This is only sensible; the record that the record object refers to is
totally arbitrary in its construction, owing its form (the fields that
compose it) only to its intended function in the database model and not to
its intended function in any simpol (or any other) program.
..
Similarly, the choice of indexes in the database model is totally
arbitrary, owing only to the database model and not to the language.
..
Making an index an attribute of a record object would be a fatal flaw in
the design of simpol.
..
Properly, you need to separate in your mind the model of the system you
are building from the model of the implementation of the system. The one
represents a design to perform a function irrespective of implementation
details, the other represents the implementation of that design in a
particular language.
..
So, from this perspective, the record with its associated fields and
indexes represents an important factor in the design of your system to
perform your function; to a large extent, the organization of your total
database IS the model of the functionality of your system. The record
object that you use in simpol is an object entity within simpol only,
which exists to enable Simpol to manipulate your record according to the
rules of simpol. The index object within simpol is another, totally
separate, entity within simpol to permit you to manipulate your indexes
within your database – and an index is not the same as a record and is not
subordinate to a record.
..
As an analogy, if your model is a statue, you can build the statue out of
wood, or bronze, or plaster of paris. In each case, you are implementing
your model, but the methods you employ in the implementation are
completely different.
..
What you are doing here is confusing the model of the entity with the tool
used to implement the model of the entity. Don't do that.

[JD Kromkowski]

What?

Thank you for the long and thoughtful post but I'm not sure I understand
all what you are getting at. What the heck do indexes have to do with
anything.
I understand that indexes are a separate object.
I also understand that an index is not a member of a record object. But
field objects ARE members of a record object, which is why you can use !
(member operator).

rCLaims is a record object. Correct.

// Below the get() method _WORKS_ just fine to retrieve the value
// of the first field of that record.
// which happens to be "CLMLASTNAM"

sfield = rCLAIMS.get(claims.firstfield)

The question is am I able to use

sfield = rCLAIMS!CLMLASTNAM

to get the same value? I.e. where
claims.firstfield.name == "CLMLASTNAM"

What does the failure and error 65 have to do with indexes?

If you look at Chapter 13. Using PPCS in SIMPOL

r.get(fld)

where r is a record object
and fld is a field object
and fld.name == "Firstname"

is equivalent to using the member operator.

r!Firstname

JDK

On 03/12/13 1:54 PM, jim wrote:
> rCLAIMS is a record object. That object has attributes, methods, and
> properties – but none of those are an index, though a pointer to the index
> that was used to locate this record is provided.
> .
> An index is a separate object, again with its own attributes, methods, and
> properties – including a pointer to the record object with which is is
> associated.
> .
> These are distinct objects; an index is not a member of a record object.
> .
> This is only sensible; the record that the record object refers to is
> totally arbitrary in its construction, owing its form (the fields that
> compose it) only to its intended function in the database model and not to
> its intended function in any simpol (or any other) program.
> .
> Similarly, the choice of indexes in the database model is totally
> arbitrary, owing only to the database model and not to the language.
> .
> Making an index an attribute of a record object would be a fatal flaw in
> the design of simpol.
> .
> Properly, you need to separate in your mind the model of the system you
> are building from the model of the implementation of the system. The one
> represents a design to perform a function irrespective of implementation
> details, the other represents the implementation of that design in a
> particular language.
> .
> So, from this perspective, the record with its associated fields and
> indexes represents an important factor in the design of your system to
> perform your function; to a large extent, the organization of your total
> database IS the model of the functionality of your system. The record
> object that you use in simpol is an object entity within simpol only,
> which exists to enable Simpol to manipulate your record according to the
> rules of simpol. The index object within simpol is another, totally
> separate, entity within simpol to permit you to manipulate your indexes
> within your database – and an index is not the same as a record and is not
> subordinate to a record.
> .
> As an analogy, if your model is a statue, you can build the statue out of
> wood, or bronze, or plaster of paris. In each case, you are implementing
> your model, but the methods you employ in the implementation are
> completely different.
> .
> What you are doing here is confusing the model of the entity with the tool
> used to implement the model of the entity. Don't do that.
>

[JD Kromkowski]

This shows the equivalence of get() and !. Indexes don't enter into the
issue.

function main()
string sResult, filename, result
integer e
sbme1 sbm
sbme1table t
sbme1record r
array tablenames

e = 0;filename = "";result = ""
wxfiledialog(.nul,"Pick a a datasource to open","C:SIMPOLUtilities
simpolserver","", "*.sbm", "open,mustexist", filename, result)

sbm =@ sbme1.new(filename,"O", error = e)
tablenames =@ array.new()
sbm.gettablenames(tablenames)
t =@ sbm.opentable(tablenames[1],error =e)
r =@ t.select()

sResult = "Value using get() is " + .tostr(r.get(t.firstfield),10) +
"{d}{a}"
sResult = sResult + "Value using member operator is " +
..tostr(r!CustomerNumber,10)
end function sResult

[Michael]

On 06/03/2013 22:19, kromkowski wrote:
> I don't understand why I get error 65 trying to use ! operator instead
> of get()
> …
> type(db1record) rCLAIMS
> integer i
> sbme1table claims
> integer iID,iCMNo
> string sfield,sfield1
> e = 0; iCMNo = 0
> claims =@ app.CLAIMS
> appw =@ getappwindowfromwindow(getmenuitemwindow(me))
> rCLAIMS =@ appw.form.selectcurrent(claims.firstindex,error = e)
> // this next line works perfectly fine
> sfield = rCLAIMS.get(claims.firstfield)
>
> // here i am trying to get the exact same thing
> // I put the if test just to make sure I was spelling
> // the field name correctly
> if claims.firstfield.name == "CLMLASTNAM"
> // this next line throws error 65 – WHY?
> sfield1 = rCLAIMS!CLMLASTNAM
> end if
>

I don't see anything obviously wrong with the code above. One thing to be aware of is that you cannot use this approach with the
volabase stuff. The member operator can be implemented by SIMPOL programmers and we use it for form controls, graphics, etc. and
even in vola1base for retrieving fields from vola1tables. But in the sbme1record and ppcstype1record objects, the use of the
member operator exceeds what can be supported in the SIMPOL programming language. Effectively it has two uses, a get() and a
put(), depending on which side of the assignment operator it falls on.

string s
type(db1record) r

r =@ appw.form.masterrecord.record

s = r!myfield
s = .ucase(s)
r!myfield = s

In the above, the first use retrieves the value of myfield from the record object. In the second case, it is putting a value into
that field. Since this sort of functionality is not possible with vola1base, we rewrote parts of the appframework and various
utilities in db1util in the most recent release to cope with this.

In those cases, you need to use something like:

s = r.get(r.table!myfield)
s = .ucase(s)
r.put(r.table!myfield, s)

Ciao, Neil

[JD Kromkowski]

Well, I know the way around the problem, because get() works.
that still does explain why the ! doesn't work and throws an error 65.
I think there is a bug. See below.

Myfield happens to be an integer. Take a look at this code.

appw =@ getappwindowfromwindow(getmenuitemwindow(me))
integer a, b, a1, b1
type(db1record) r, r1
r =@ appw.form.masterrecord.record

//this below works which I knew
a = r.get(r.table!CMNo)
//and so does this as it should
a1 = r!CMNo

// But look at this
r1 =@ appw.form.selectcurrent(r.table.firstindex,error = e)

//you would think that r and r1 are essentially the same object.
//But inspect them and compare. THEY ARE NOT. WHY?

//And here is where is gets funky
// you can get c fine
c = r1.get(r.table!CMNo)

// BUT both of these will produce error 65

b = r1.get(r1.table!CMNo)
b1 = r1!CMNo

//To me this means either that r1 is actually a volabase
//OR maybe there is something messed up with selectcurrent()?

JDK

On 03/19/13 4:31 PM, Neil Robinson wrote:
> On 06/03/2013 22:19, kromkowski wrote:
>> I don't understand why I get error 65 trying to use ! operator instead
>> of get()
>> …
>> type(db1record) rCLAIMS
>> integer i
>> sbme1table claims
>> integer iID,iCMNo
>> string sfield,sfield1
>> e = 0; iCMNo = 0
>> claims =@ app.CLAIMS
>> appw =@ getappwindowfromwindow(getmenuitemwindow(me))
>> rCLAIMS =@ appw.form.selectcurrent(claims.firstindex,error = e)
>> // this next line works perfectly fine
>> sfield = rCLAIMS.get(claims.firstfield)
>>
>> // here i am trying to get the exact same thing
>> // I put the if test just to make sure I was spelling
>> // the field name correctly
>> if claims.firstfield.name == "CLMLASTNAM"
>> // this next line throws error 65 – WHY?
>> sfield1 = rCLAIMS!CLMLASTNAM
>> end if
>>
>
> I don't see anything obviously wrong with the code above. One thing to be aware of is that you cannot use this approach with the
> volabase stuff. The member operator can be implemented by SIMPOL programmers and we use it for form controls, graphics, etc. and
> even in vola1base for retrieving fields from vola1tables. But in the sbme1record and ppcstype1record objects, the use of the
> member operator exceeds what can be supported in the SIMPOL programming language. Effectively it has two uses, a get() and a
> put(), depending on which side of the assignment operator it falls on.
>
> string s
> type(db1record) r
>
> r =@ appw.form.masterrecord.record
>
> s = r!myfield
> s = .ucase(s)
> r!myfield = s
>
> In the above, the first use retrieves the value of myfield from the record object. In the second case, it is putting a value into
> that field. Since this sort of functionality is not possible with vola1base, we rewrote parts of the appframework and various
> utilities in db1util in the most recent release to cope with this.
>
> In those cases, you need to use something like:
>
> s = r.get(r.table!myfield)
> s = .ucase(s)
> r.put(r.table!myfield, s)
>
> Ciao, Neil
>

[Michael]

On 20/03/2013 17:02, kromkowski wrote:
> Well, I know the way around the problem, because get() works.
> that still does explain why the ! doesn't work and throws an error 65.
> I think there is a bug. See below.
>
> Myfield happens to be an integer. Take a look at this code.
>
> appw =@ getappwindowfromwindow(getmenuitemwindow(me))
> integer a, b, a1, b1
> type(db1record) r, r1
> r =@ appw.form.masterrecord.record
>
> //this below works which I knew
> a = r.get(r.table!CMNo)
> //and so does this as it should
> a1 = r!CMNo
>
> // But look at this
> r1 =@ appw.form.selectcurrent(r.table.firstindex,error = e)
>
> //you would think that r and r1 are essentially the same object.
> //But inspect them and compare. THEY ARE NOT. WHY?
>
> //And here is where is gets funky
> // you can get c fine
> c = r1.get(r.table!CMNo)
>
> // BUT both of these will produce error 65
>
> b = r1.get(r1.table!CMNo)
> b1 = r1!CMNo
>
> //To me this means either that r1 is actually a volabase
> //OR maybe there is something messed up with selectcurrent()?

Unfortunately, without a piece of code and some data to play with, it is hard to make any clear pronouncements here as to what is
wrong.

r1 will be a record of the same type family as that of appw.form.mastertable.table.

r and r1 are not the same object, even if they refer to the same record. They were both created independently of one another
through a read operation, and in fact, the selection index may well be different if that was changed in the selectcurrent() call.

Only one of them could ever be locked at the same time as the other record object exists. In fact, you have to read a new record
object to lock it.

Ciao, Neil

[JD Kromkowski]

On 03/20/13 5:27 PM, Neil Robinson wrote:
> Unfortunately, without a piece of code and some data to play with, it is hard to make any clear pronouncements here as to what is
> wrong.
>
> Only one of them could ever be locked at the same time as the other record object exists. In fact, you have to read a new record
> object to lock it.
>
> Ciao, Neil

Sorry some imprecision in language.

I know that r and r1 are not the "same" object but they should be
essentially duplicate (although separate and distinct) type(db1record)
objects. In other words, if we "dumped" them they (I would have
thought) should be indistinguishable. But they are not.

I've dumped them. And now I see

r =@ appw.form.masterrecord.record

<id>00000</id>
<name>r</name>
<type>type(db1record)</type>
<properties>
<object>
<id>00001</id>
<name>type</name>
<type>type</type>
<value><type: sbme1record></value>
….
ie. an sbme1record

However

r1 =@ appw.form.selectcurrent(r.table.firstindex,error = e)

r1 is a "dataform1record".

<id>00000</id>
<name>r1</name>
<type>type(db1record)</type>
<properties>
<object>
<id>00001</id>
<name>type</name>
<type>type</type>
<value><type: dataform1record></value>

….

So, is it supposed to be the case that the ! operator doesn't work with
dataform1record just as it doesn't work with volarecords? Or is this a bug.

(I've attached the dump of r and r1. Sorry not attached because it is
too big apparent to be an attachment.)

Upon further investigation, if I do this

r1 =@ appw.form.selectcurrent(r.table.firstindex,error = e)

r1 =@ r1.selectcurrent(r1.table.firstindex)

I can now use the ! operator.

So, IMO, I think this is a bug (or a choice maybe). To me

appw.form.selectcurrent()

should generally return the same thing as

appw.form.masterrecord.record

the only difference being that the selectcurrent() method give you
opportunity to lock a record.

JDK

[Michael]

On 20/03/2013 22:21, kromkowski wrote:
> Sorry some imprecision in language.
>
> I know that r and r1 are not the "same" object but they should be
> essentially duplicate (although separate and distinct) type(db1record)
> objects. In other words, if we "dumped" them they (I would have
> thought) should be indistinguishable. But they are not.
>
> I've dumped them. And now I see
>
> r =@ appw.form.masterrecord.record
>
> ie. an sbme1record
>
> However
>
> r1 =@ appw.form.selectcurrent(r.table.firstindex,error = e)
>
> r1 is a "dataform1record".
>
> So, is it supposed to be the case that the ! operator doesn't work with
> dataform1record just as it doesn't work with volarecords? Or is this a bug.

A dataform1record is a wrapper used by dataform1 in order to carry more information around than is possible with a
type(db1record). It is generally not used much externally, and it might be reasonable to suggest that the return value could be a
type(db1record). The only risk I see with that is making sure that nothing currently depends on that return value (including other
user programs). Please note that masterrecord is also a dataform1record object. So in essence, you can retrieve the .record
property of the return value.

> (I've attached the dump of r and r1. Sorry not attached because it is
> too big apparent to be an attachment.)
>
> Upon further investigation, if I do this
>
> r1 =@ appw.form.selectcurrent(r.table.firstindex,error = e)
>
> r1 =@ r1.selectcurrent(r1.table.firstindex)
>
> I can now use the ! operator.
>
> So, IMO, I think this is a bug (or a choice maybe). To me

Not a bug, a design choice.

> appw.form.selectcurrent()
>
> should generally return the same thing as
>
> appw.form.masterrecord.record

Actually it returns the same thing as appw.form.masterrecord.

> the only difference being that the selectcurrent() method give you
> opportunity to lock a record.

You seem to be deciding whether to make use of form.masterrecord.record, or to make a call to the selectcurrent() method of the
form. There is no advantage to the selectcurrent() call unless you need to lock or change the selection index. In some cases you
would do so, in others you wouldn't.

Ciao, Neil

[JD Kromkowski]

On 03/21/13 2:54 PM, Neil Robinson wrote:
>> appw.form.selectcurrent()
>> >
>> >should generally return the same thing as
>> >
>> >appw.form.masterrecord.record
> Actually it returns the same thing as appw.form.masterrecord.
>

Ok. But the point of this thread is why was I getting an ERROR 65.
(nothing to do with indexes as I think Jim was suggesting)

The reason I was getting ERROR 65 is that you can use the ! operator
ONLY with

appw.form.masterrecord.record

NOT with

appw.form.masterrecord

So, I am getting this error 65 because

appw.form.selectcurrent() is returning

appw.form.masterrecord

NOT

appwform.masterrecord.record

That both of these are considered type(db1record) objects is a bit
confusing when coupled with additional idea that you can use ! operator
with type(db1record), because obviously there are some types of
db1record where this isn't true (i.e. a dataformrecord cannot use !
operator).

On 03/21/13 2:54 PM, Neil Robinson wrote:
> A dataform1record is a wrapper used by dataform1 in order to carry
more information around than is possible with a
> type(db1record). It is generally not used much externally, and it
might be reasonable to suggest that the return value could be a
> type(db1record).

It's not really a suggestion that datform1record is a type(db1record).
That is the realty because there is no error when you use that type.

The only reason I used selectcurrent() was because from the
documentation regarding …. form.selectcurrent()

"…This works similarly to the standard selectcurrent() method of the
ppcstype1record, though it works with sbme1record and vola1record as
well. Also updates the form, any form links, and will call any defined
onselect event handler (for calculated form content based on the data)."

And right before that:

"… To modify the fields of the target record, or retrieve values, use
the dataform1.masterrecord.record!fieldname…."

So I was under the assumption that selectcurrent() would in fact return
the masterrecord.record, and hence ! would be valid.

JDK

[Michael]

On 21/03/2013 22:59, kromkowski wrote:
> On 03/21/13 2:54 PM, Neil Robinson wrote:
>>> appw.form.selectcurrent()
>>>>
>>>> should generally return the same thing as
>>>>
>>>> appw.form.masterrecord.record
>> Actually it returns the same thing as appw.form.masterrecord.
>>
>
> Ok. But the point of this thread is why was I getting an ERROR 65.
> (nothing to do with indexes as I think Jim was suggesting)
>
> The reason I was getting ERROR 65 is that you can use the ! operator
> ONLY with
>
> appw.form.masterrecord.record
>
> NOT with
>
> appw.form.masterrecord
>
> So, I am getting this error 65 because
>
> appw.form.selectcurrent() is returning
>
> appw.form.masterrecord
>
> NOT
>
> appwform.masterrecord.record
>
> That both of these are considered type(db1record) objects is a bit
> confusing when coupled with additional idea that you can use ! operator
> with type(db1record), because obviously there are some types of
> db1record where this isn't true (i.e. a dataformrecord cannot use !
> operator).

I understand, but this is a special case regarding the record object anyway, as I have explained elsewhere. Even if I wanted to, I
couldn't implement in SIMPOL the get and put operations that are used in this case. That is why it doesn't even work with
vola1record. At the same time, the get() and put() methods *do* work with it. Although the table!fieldname bit won't, but that is
a reasonable enhancement request.

Ciao, Neil

[Author]

Posts