business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID) - Forum - OpenEdge Development - Progress Community

business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)

 Forum

business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)

This question is answered

I'm creating a vanilla plain business entity. in a master-detail relation.

The first BE, (master) works find, but when making the detail BE, it compiles ok, but when issuing the call to appserver, it shows those errors on log.

Detail table has no unique index, but I have some other pairs of BE in equally circumstances, and they works as expected.

I don't know if it's related to a annoying behavior I've seen frequently:

When modifying a table, normally adding a field or so, in PDSOE (by calling data dictionary, as the option to add column to table and so, in the db structure view, won't work for me) it takes really long to be able to see the modified field in DB structure view. By long I mean several (really quite a few) restarts of PDSOE.  But now I finally can't refresh the DB Structure view, by using the refresh drop option, nor restarting pdsoe (right now I count some 20 restarts of pdsoe, and can't see the field in db view).   code compiles ok, syntax proposition won't handle that field... but now I don't know if this is related to errors (by the way, the knowledgebase reports totally diferent conditions for those error numbers...

Any help would be very appreciated.

Verified Answer
  • I like those errors… in any language. As they are clear in what you need to do to avoid this.
     
    Assumingly, the DB table that the DATA-SOURCE works against has no unique index. The ProDataset/DATA-SOURCE needs an unique index in order to find the DB record for you which should be updated. It prefers to do that based on UNIQUE indexes. When – and I’m not going to comment on that – your DB table has no unique index, the DATA-SOURCE asks you to provide the KEYS option in the DEFINE DATA-SOURCE statement. Which is very kind of it.
     
    Alternatively you can also use ROWID’s. You can add a ROWID field to your Temp-Table and in the ATTACH-DATA-SOURCE map that using “<your rowid TT-field>,ROWID(your db table)”. Then use KEYS (ROWID).

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

All Replies
  • We use HEX-ENCODE(GENERATE-UUID).  Universally unique sounds more appealing than globally unique.
     
    Jeff Ledbetter
    skype: jeff.ledbetter
     
    From: Peter Judge [mailto:bounce-pjudge@community.progress.com]
    Sent: Tuesday, April 7, 2015 12:14 PM
    To: TU.OE.Development@community.progress.com
    Subject: RE: [Technical Users - OE Development] business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)
     
    Reply by Peter Judge
    Use the GUID() function which returns a character value. Performance of GUID is /very/quick.
     
    -- peter
     
    From: OctavioOlguin [mailto:bounce-OctavioOlguin@community.progress.com]
    Sent: Tuesday, 07 April, 2015 13:06
    To: TU.OE.Development@community.progress.com
    Subject: RE: [Technical Users - OE Development] business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)
     
    Reply by OctavioOlguin

    And on your hijacked post ... (jijiji)

    Do you use the GUID'ed value of a GENERATE-UUID value?

    extra-processing at create time?

    Avoiding storing raw values on db?

    Any thoughts?

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com

  • Mostly in agreement with Mike but strongly disagree on niceness of the KEYS option, that should not be there at all but now because for some strange reason made through should be avoided like a plague, much more than the use index option but that might be just me.

    Giving the developer the option to invent primary keys where not enforced by a unique index is bad, even if there is an informal primary key now that can change over time and then I can imagine one will forget to update the keys in at least one place in the whole code base.

  • All right....

    form now on, I'll create my tables with unique PK, by guid'em

    Thanks!!!

  • Peter Judge

    and no, your poor eyes not being able read them is not a sufficient excuse to not use them  :)

    -- peter

    That's an excuse I haven't heard so far :-)
    I've heard not being able to remember them... when coding your ad-hoc tests. But using a technical/non meaning ful key does not forbit to use alternative human meaning ful key values. 

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • And....

    How do you name the field on the table?...

    fGUIID?   PK?, what is more natural, years after?

  • CustomerGuid or CustomerID
    SalesRepGuid or SalesRepID
    OrderGuid or OrderID

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • I go with just ID on the table itself and then names like CustomerID in a related table for the join.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • And...

    On master,detail,  you create GUID as PK for child table also?  as you already should have a GUID as FK to master,

  • After a second thought,

    I respond myself:       yes.        (Isn't this the origin of this long debate? To be able to update the records from a dataset )

  • Yes, Order has an ID, OrderLine has its own ID and OrderID pointing to the Order, and ShippingLine or whatever has its own ID and OrderLIneID pointing to the OrderLine.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Finally, what's the winner expression to get the PK?:

    Jeff proposes:  HEX-ENCODE(GENERATE-UUID),   wich is RAW datatype. and universal reach. Should it be STRING()'ed ??

    Mike suggested: GUID(GENERATE-UUID)   (Note the help file suggests that GUID() should be enough, but testing on scratchpad, it won't behaves as advertised) and global reach

  • I always use “GUID”. No parenthesis.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • I've been using base64-encode(generate-uuid), but it means you need to use case-sensitive fields.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Isn’t a GUID case sensitive anyway?
     
    James Palmer |Application Developer
    Tel: 01253 785103 | Fax: 01253 785001 | Web: www.inenco.com | Twitter : @inenco
    footer
     
    From: Thomas Mercer-Hursh [mailto:bounce-tamhas@community.progress.com]
    Sent: 07 April 2015 21:55
    To: TU.OE.Development@community.progress.com
    Subject: RE: [Technical Users - OE Development] business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)
     
    Reply by Thomas Mercer-Hursh

    I've been using base64-encode(generate-uuid), but it means you need to use case-sensitive fields.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.




    This email has been scanned for email related threats and delivered safely by Mimecast.
    For more information please visit http://www.mimecast.com
  • GUID’s don’t care about the case. They only contain numbers and A-F and colons or hyphens – depending on the implementation.
     
    When you base64-encode the RAW GENERATE-UUID value, the result is case-sensitive. I consider that way too dangerous to risk this for a few bytes it saves!

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.