business entity- errors 11895 and 12478 (no SAVE-WHERE-STRIN

Posted by OctavioOlguin on 06-Apr-2015 21:46

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.

Posted by Mike Fechner on 07-Apr-2015 10:48
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).

All Replies

Posted by Garry Hall on 07-Apr-2015 09:28

I suspect the PDSOE behaviour you are seeing is not related to the errors in the BE. I would log an issue with Tech Support about that.

Does this BE work if you define a unique index on the detail table? As per the (11895) error, you need either a unique index or a KEYS phrase on the data-source for the detail table. Can you attach the code and (temp-)table definitions? The (12478) message relates to disabling Database features, so I am not sure how this is related to your issue.

Posted by OctavioOlguin on 07-Apr-2015 10:32

This is what I have:

/* dwdevold.i*/
DEFINE TEMP-TABLE ttdwDevolucionD BEFORE-TABLE bttdwDevolucionD
   FIELD Sucursal   AS INTEGER   INITIAL "0"
   FIELD Devolucion AS INTEGER   INITIAL "0" LABEL "Num Dev"
   FIELD Fecha      AS DATETIME  LABEL "Fecha dev."
   FIELD Origen     AS CHARACTER INITIAL "M" LABEL "Origen"
   FIELD Control#   AS DECIMAL   INITIAL "0" LABEL "Num Etiqueta"
   FIELD Articulo   AS CHARACTER LABEL "Artículo"
   FIELD Cantidad   AS DECIMAL   INITIAL "0"
   FIELD TipoDev    AS INTEGER   INITIAL "0" LABEL "Tipo"
   INDEX SucDev IS PRIMARY UNIQUE  
Sucursal DESCENDING     Devolucion DESCENDING    
Articulo DESCENDING     Cantidad DESCENDING    TipoDev DESCENDING
   INDEX SucFecha                 Sucursal DESCENDING     Fecha    DESCENDING .
DEFINE DATASET dsdwDevolucionD FOR ttdwDevolucionD.

and this is the BE  class file:

USING Progress.Lang.*.
USING OpenEdge.BusinessLogic.BusinessEntity.
BLOCK-LEVEL ON ERROR UNDO, THROW.
CLASS DW.dwDevolD INHERITS BusinessEntity:
   /*----------------------------------------------------------------------------------*/
{"DW\dwdevold.i"}
   DEFINE DATA-SOURCE srcdwDevolucionD FOR dwh.dwDevolucionD.
   CONSTRUCTOR PUBLIC dwDevolD():
    DEFINE VAR hDataSourceArray AS HANDLE NO-UNDO EXTENT 1.
       DEFINE VAR cSkipListArray AS CHAR NO-UNDO EXTENT 1.
       SUPER (DATASET dsdwDevolucionD:HANDLE).
       /* Data Source for each table in dataset. Should be in table order as defined in DataSet */
    hDataSourceArray[1] =  DATA-SOURCE srcdwDevolucionD:HANDLE.
    /* Skip-list entry for each table in dataset. Should be in temp-table order  as defined in DataSet */
       /* Each skip-list entry is a comma-separated list of field names, to be ignored in create stmt */
    cSkipListArray[1] = "".
    THIS-OBJECT:ProDataSource = hDataSourceArray.
       THIS-OBJECT:SkipList = cSkipListArray.
   END CONSTRUCTOR.
   /*------------------------------------------------------------------------------
           Purpose:  Get one or more records, based on a filter string                                                                    
           Notes:                                                                        
   ------------------------------------------------------------------------------*/
   METHOD PUBLIC VOID ReaddwDevolD(
    INPUT filter AS CHARACTER,
    OUTPUT DATASET dsdwDevolucionD):
    SUPER:ReadData(filter).
   END METHOD.
   /*------------------------------------------------------------------------------
           Purpose: Create one or more new records                                                              
           Notes:                                                                        
   ------------------------------------------------------------------------------*/
   METHOD PUBLIC VOID CreatedwDevolD(INPUT-OUTPUT DATASET dsdwDevolucionD):    
    DEFINE VAR hDataSet AS HANDLE NO-UNDO.
       hDataSet = DATASET dsdwDevolucionD:HANDLE.
       SUPER:CreateData(DATASET-HANDLE hDataSet BY-REFERENCE).        
   END METHOD.  .........

This is the last version, with all the fields (almost) in the PK, and yet it shows the same errors:

[15/04/07@10:21:38.453-0500] P-000300 T-005008 1 AS -- (Procedure: 'dw/pdwDevolD.p' Line:143) Sys error 1 : No se puede obtener SAVE-WHERE-STRING por que no hay frase KEYS para la definicion de DATA-SOURCE y no se encontro un indice único en dwDevolucionD. (11895)
[15/04/07@10:21:38.453-0500] P-000300 T-005008 1 AS -- (Procedure: 'dw/pdwDevolD.p' Line:143) Sys error 2 : No se puede generar FIND para dwDevolucionD en DATA-SOURCE-ROWID. (14278)


The errors are messages I sent form a catch block inside the handler procedure on the appserver....

Thanks!

Posted by Peter Judge on 07-Apr-2015 10:40
What are the indexes on the dwh.dwDevolucionD table?
 
 
-- peter
 
[collapse]
From: OctavioOlguin [mailto:bounce-OctavioOlguin@community.progress.com]
Sent: Tuesday, 07 April, 2015 11:33
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

This is what I have:

/* dwdevold.i*/
DEFINE TEMP-TABLE ttdwDevolucionD BEFORE-TABLE bttdwDevolucionD
   FIELD Sucursal   AS INTEGER   INITIAL "0"
   FIELD Devolucion AS INTEGER   INITIAL "0" LABEL "Num Dev"
   FIELD Fecha      AS DATETIME  LABEL "Fecha dev."
   FIELD Origen     AS CHARACTER INITIAL "M" LABEL "Origen"
   FIELD Control#   AS DECIMAL   INITIAL "0" LABEL "Num Etiqueta"
   FIELD Articulo   AS CHARACTER LABEL "Artículo"
   FIELD Cantidad   AS DECIMAL   INITIAL "0"
   FIELD TipoDev    AS INTEGER   INITIAL "0" LABEL "Tipo"
   INDEX SucDev IS PRIMARY UNIQUE  
Sucursal DESCENDING     Devolucion DESCENDING    
Articulo DESCENDING     Cantidad DESCENDING    TipoDev DESCENDING
   INDEX SucFecha                 Sucursal DESCENDING     Fecha    DESCENDING .
DEFINE DATASET dsdwDevolucionD FOR ttdwDevolucionD.

and this is the BE  class file:

USING Progress.Lang.*.
USING OpenEdge.BusinessLogic.BusinessEntity.
BLOCK-LEVEL ON ERROR UNDO, THROW.
CLASS DW.dwDevolD INHERITS BusinessEntity:
   /*----------------------------------------------------------------------------------*/
{"DW\dwdevold.i"}
   DEFINE DATA-SOURCE srcdwDevolucionD FOR dwh.dwDevolucionD.
   CONSTRUCTOR PUBLIC dwDevolD():
    DEFINE VAR hDataSourceArray AS HANDLE NO-UNDO EXTENT 1.
       DEFINE VAR cSkipListArray AS CHAR NO-UNDO EXTENT 1.
       SUPER (DATASET dsdwDevolucionD:HANDLE).
       /* Data Source for each table in dataset. Should be in table order as defined in DataSet */
    hDataSourceArray[1] =  DATA-SOURCE srcdwDevolucionD:HANDLE.
    /* Skip-list entry for each table in dataset. Should be in temp-table order  as defined in DataSet */
       /* Each skip-list entry is a comma-separated list of field names, to be ignored in create stmt */
    cSkipListArray[1] = "".
    THIS-OBJECT:ProDataSource = hDataSourceArray.
       THIS-OBJECT:SkipList = cSkipListArray.
   END CONSTRUCTOR.
   /*------------------------------------------------------------------------------
           Purpose:  Get one or more records, based on a filter string                                                                    
           Notes:                                                                        
   ------------------------------------------------------------------------------*/
   METHOD PUBLIC VOID ReaddwDevolD(
    INPUT filter AS CHARACTER,
    OUTPUT DATASET dsdwDevolucionD):
    SUPER:ReadData(filter).
   END METHOD.
   /*------------------------------------------------------------------------------
           Purpose: Create one or more new records                                                              
           Notes:                                                                        
[/collapse]
Posted by Mike Fechner on 07-Apr-2015 10:48
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).
Posted by OctavioOlguin on 07-Apr-2015 10:55

Yes... I was about to inform that the database table, doesn't has a unique index....

it has (Sucursal + Devolucion) and  (Sucursal + Fecha)

:(

Posted by OctavioOlguin on 07-Apr-2015 11:01

(a side question, Mike)

You mean that a solid design has unique index for every table? even I have to invent one for some of them?  All my master tables has uniques, but normally, the details not necessarily have one, as not needed at all...... well, until now   :(

It is not mandatory by Relational design, but for performance purposes? besides to avoid the problems in'm facing rigth now?

Thanks for a very nutritive chat...

Posted by Peter Judge on 07-Apr-2015 11:08
This question may start a vigourous debate :)
 
IMO all tables must have a unique index. Must. Can be a composite key (eg order-num + line-num) or an opaque key, but must have one.
 
--  peter
 
[collapse]
From: OctavioOlguin [mailto:bounce-OctavioOlguin@community.progress.com]
Sent: Tuesday, 07 April, 2015 12:02
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

(a side question, Mike)

You mean that a solid design has unique index for every table? even I have to invent one for some of them?  All my master tables has uniques, but normally, the details not necessarily have one, as not needed at all...... well, until now   :(

It is not mandatory by Relational design, but for performance purposes? besides to avoid the problems in'm facing rigth now?

Thanks for a very nutritive chat...

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by OctavioOlguin on 07-Apr-2015 11:09

   DEFINE DATA-SOURCE srcdwDevolucionD FOR dwh.dwDevolucionD KEYS (Sucursal, Devolucion, Articulo, Cantidad, TipoDev ).

Did the trick...

Thanks a lot!

Posted by Mike Fechner on 07-Apr-2015 11:10
Hehe, hijacking your own tread J
 
I’d even go a step further. Every table should have a single field unique index based on a value not meaningful and not visible to normal users. Let it be a sequence or a GUID (my preference) or whatever. But this should describe the “identity” of a record for its life time. And it should not be a technical value like ROWID’s or RECID’s that change during DBA tasks.
 

-          as you are facing now, ProDatasets work best with unqiue indexes.

-          Users may want to change every field values that they see on the screen. With a non meaningful key, they can change whatever they want without affecting relations to other tables.

-          generic comments or attachments work best with standardized keys

 
I’m sure there are other reasons.

 

Posted by Peter Judge on 07-Apr-2015 11:15

+1 for the premise and +1 for using GUIDs (and no, your poor eyes not being able read them is not a sufficient excuse to not use them  :)

Note that ROWIDs are becoming steadily less unique across a *database* with successive releases.

-- peter

Posted by Thomas Mercer-Hursh on 07-Apr-2015 11:22

Strong agreement with Mike on this one.  The unique identity of a record should remain unique, whatever you do to it.  There are many easily imagined scenarios where this can keep you out of trouble.  And, there is no reason to display that identifier to the user.

Posted by OctavioOlguin on 07-Apr-2015 11:22

!!!!!!! BUT  !!!!!!

When I check the dw.dwdevolucionD table, it has no records,  the client didn't got any error nor rejection from the server...

and the server didn't record anything on the broker or server logs...

I'll delete the BE and start from 0...

Posted by OctavioOlguin on 07-Apr-2015 12:04

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?

Posted by Peter Judge on 07-Apr-2015 12:13
Use the GUID() function which returns a character value. Performance of GUID is /very/quick.
 
-- peter
 
[collapse]
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.

[/collapse]
Posted by Mike Fechner on 07-Apr-2015 12:14
How many ten thousands of records do you try to create per second that the GUID function becomes relevant?

The advantage of a GUID is that the client can create them as well. Very helpful when submitting datasets with many new parent records and many related child at once.

I don't base64 encode the raw values of generate-uuid as that may become ambiguous when not treated case-sensitive.

And a raw value does not work to well on some output channels.

So all on all. I believe in the GUID method and a character value.

Von meinem Windows Phone gesendet

Von: OctavioOlguin
Gesendet: ‎07.‎04.‎2015 19:05
An: TU.OE.Development@community.progress.com
Betreff: 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.

Posted by Jeff Ledbetter on 07-Apr-2015 12:24
We use HEX-ENCODE(GENERATE-UUID).  Universally unique sounds more appealing than globally unique.
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
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
 
[collapse]
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.

[/collapse][/collapse]
Posted by Marian Edu on 07-Apr-2015 12:32

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.

Posted by OctavioOlguin on 07-Apr-2015 12:48

All right....

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

Thanks!!!

Posted by Mike Fechner on 07-Apr-2015 12:52

[quote user="Peter Judge"]

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

-- peter

[/quote]
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. 
Posted by OctavioOlguin on 07-Apr-2015 14:25

And....

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

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

Posted by Mike Fechner on 07-Apr-2015 14:33
CustomerGuid or CustomerID
SalesRepGuid or SalesRepID
OrderGuid or OrderID

Posted by Thomas Mercer-Hursh on 07-Apr-2015 14:36

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

Posted by OctavioOlguin on 07-Apr-2015 14:39

And...

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

Posted by OctavioOlguin on 07-Apr-2015 14:49

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 )

Posted by Thomas Mercer-Hursh on 07-Apr-2015 14:53

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.

Posted by OctavioOlguin on 07-Apr-2015 15:38

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

Posted by Mike Fechner on 07-Apr-2015 15:42
I always use “GUID”. No parenthesis.

 

Posted by Thomas Mercer-Hursh on 07-Apr-2015 15:54

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

Posted by James Palmer on 07-Apr-2015 15:56
Isn’t a GUID case sensitive anyway?
 
James Palmer |Application Developer
Tel: 01253 785103 | Fax: 01253 785001 | Web: www.inenco.com | Twitter : @inenco
footer
 
[collapse]
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
[/collapse]
Posted by Mike Fechner on 07-Apr-2015 16:00
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!

Posted by Jeff Ledbetter on 07-Apr-2015 16:15
No need to use STRING. HEX-ENCODE produces a string of the raw output from GENERATE-UUID.
 
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: OctavioOlguin [mailto:bounce-OctavioOlguin@community.progress.com]
Sent: Tuesday, April 7, 2015 3:39 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 OctavioOlguin

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

Jeff proposes:  HEX-ENCODE(GENERATE-UUID),   wich is RAW datatype. and universal reach. It should be STRING()'ed to

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

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by Jeff Ledbetter on 07-Apr-2015 16:16
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!”
 
Agreed. I have first-hand experience with this hair-pulling nightmare. Don’t do it!
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
Sent: Tuesday, April 7, 2015 4:01 PM
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] AW: business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)
 
Reply by Mike Fechner
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!
Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by Mike Fechner on 07-Apr-2015 16:24
No need to use STRING. HEX-ENCODE produces a string of the raw output from GENERATE-UUID.“
 
Strange. According to the docs Jeff is right. It is supposed to return a CHARACTER value. However the AVM seems to disagree (11.5 64 bit):
 
message hex-encode (generate-uuid)
 
returns
 
INPUT/OUTPUT operations are not allowed with RAW, ROWID, MEMPTR, BLOB, CLOB or LONGCHAR type variables. (11382)
 
Is that a bug or a feature?
 
However Jeff, the output of string(hex-encode(generate-uuid)) and just replace (guid, “-“, “”) look pretty similar. So I question your expected difference between globally unique and universally unique. As we haven’t found E.T. yet and the idiots have not yet done their one-way trip to the Mars globally seems to be equal to universally.
Posted by Jeff Ledbetter on 07-Apr-2015 16:43
I think the message statement doesn’t work just because of the presence of the generate-uuid function. That’s what I have always told myself as I have seen it before. J
 
We use hex-encode(generate-uuid) all over the place and store in character fields.
 
So I question your expected difference between globally unique and universally unique.”
 
I just wanted to future-proof my IDs.
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
Sent: Tuesday, April 7, 2015 4:25 PM
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] AW: business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)
 
Reply by Mike Fechner
No need to use STRING. HEX-ENCODE produces a string of the raw output from GENERATE-UUID.“
 
Strange. According to the docs Jeff is right. It is supposed to return a CHARACTER value. However the AVM seems to disagree (11.5 64 bit):
 
message hex-encode (generate-uuid)
 
returns
 
INPUT/OUTPUT operations are not allowed with RAW, ROWID, MEMPTR, BLOB, CLOB or LONGCHAR type variables. (11382)
 
Is that a bug or a feature?
 
However Jeff, the output of string(hex-encode(generate-uuid)) and just replace (guid, “-“, “”) look pretty similar. So I question your expected difference between globally unique and universally unique. As we haven’t found E.T. yet and the idiots have not yet done their one-way trip to the Mars globally seems to be equal to universally.
Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by OctavioOlguin on 07-Apr-2015 16:57

Bingo.. GUID simply will do the trick!

(Btw, as Mike  says, I also consider prone to errors, that some other developer bypasses the case sensitivity of a field...)

Thanks!

Posted by mopfer on 07-Apr-2015 17:05
If all of the code that generates the GUID values always runs on the same machine, then the ABL function is all you need. 
 
If the code that generates the GUID values runs on more than one machine, then you’ll want to add an extra value that is specific to the current session to the generated GUID to avoid duplicates.  The scope of “global” or “universal” for that function is only for one machine. 
 
We have had cases where code running on two different clients generated the same GUID values and resulted in duplicate key errors when the second set of data of was pushed into the permanent database.
 
The duplication doesn’t happen very often, but just often enough that we have to handle it.
 
 
Mark Opfer
402.330.6620 (e) 114 | mopfer@dmsi.com
 
PC15!  SAVE THE DATE
    September 21 – 25, 2015
 
 
[collapse]
From: OctavioOlguin [mailto:bounce-OctavioOlguin@community.progress.com]
Sent: Tuesday, April 07, 2015 4:58 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 OctavioOlguin

Bingo.. GU simply will do the trick!

(Btw, as Mike  says, I also consider prone to errors, that some other developer bypasses the case sensitivity of a field...)

Thanks!

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by Tim Kuehn on 07-Apr-2015 17:11
My guess is that HEX-ENCODE returns a LONGCHAR, not a regular string - hence the error.

[collapse]
On Tue, Apr 7, 2015 at 5:24 PM, Mike Fechner <bounce-mikefechner@community.progress.com> wrote:
Reply by Mike Fechner
No need to use STRING. HEX-ENCODE produces a string of the raw output from GENERATE-UUID.“
 
Strange. According to the docs Jeff is right. It is supposed to return a CHARACTER value. However the AVM seems to disagree (11.5 64 bit):
 
message hex-encode (generate-uuid)
 
returns
 
INPUT/OUTPUT operations are not allowed with RAW, ROWID, MEMPTR, BLOB, CLOB or LONGCHAR type variables. (11382)
 
Is that a bug or a feature?
 
However Jeff, the output of string(hex-encode(generate-uuid)) and just replace (guid, “-“, “”) look pretty similar. So I question your expected difference between globally unique and universally unique. As we haven’t found E.T. yet and the idiots have not yet done their one-way trip to the Mars globally seems to be equal to universally.
Stop receiving emails on this subject.

Flag this post as spam/abuse.




--
Tim Kuehn:  Senior Consultant  - TDK Consulting Services
President - Ontario PUG 
Program Committee Chair - PUG Challenge Americas, 
Course Instructor: Intro to OO Concepts for Procedural Programmers

Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
[/collapse]
Posted by Mike Fechner on 07-Apr-2015 17:13
That would be a docu bug.
Von: Tim Kuehn [mailto:bounce-timk519@community.progress.com]
Gesendet: Mittwoch, 8. April 2015 00:12
An: TU.OE.Development@community.progress.com
Betreff: Re: [Technical Users - OE Development] AW: business entity- errors 11895 and 12478 (no SAVE-WHERE-STRING and can't make FIND for DATA-SOURCE-ROWID)
 
Reply by Tim Kuehn
My guess is that HEX-ENCODE returns a LONGCHAR, not a regular string - hence the error.
 
On Tue, Apr 7, 2015 at 5:24 PM, Mike Fechner <bounce-mikefechner@community.progress.com> wrote:
Reply by Mike Fechner
No need to use STRING. HEX-ENCODE produces a string of the raw output from GENERATE-UUID.“
 
Strange. According to the docs Jeff is right. It is supposed to return a CHARACTER value. However the AVM seems to disagree (11.5 64 bit):
 
message hex-encode (generate-uuid)
 
returns
 
INPUT/OUTPUT operations are not allowed with RAW, ROWID, MEMPTR, BLOB, CLOB or LONGCHAR type variables. (11382)
 
Is that a bug or a feature?
 
However Jeff, the output of string(hex-encode(generate-uuid)) and just replace (guid, “-“, “”) look pretty similar. So I question your expected difference between globally unique and universally unique. As we haven’t found E.T. yet and the idiots have not yet done their one-way trip to the Mars globally seems to be equal to universally.
Stop receiving emails on this subject.

Flag this post as spam/abuse.



 
--
Tim Kuehn:  Senior Consultant  - TDK Consulting Services
President - Ontario PUG 
Program Committee Chair - PUG Challenge Americas, 
Course Instructor: Intro to OO Concepts for Procedural Programmers

Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by OctavioOlguin on 07-Apr-2015 17:27

Then it should be good for us to know the variant of uuid the AVM creates, as one of the I remeber derives from mac address.. didn't?

Posted by Thomas Mercer-Hursh on 04-May-2015 11:18

Just a footnote to this old thread.  There are a couple of issues outstanding.

One is a docu-bug.  The manual as of 11.5 gives the syntax for GUID as

GUID( [UUID] )

when in fact it is

GUID[( UUID )]

i.e., the UUID seed is optional, but if it is omitted, the parens must be omitted too.

My reading of the manual ... which might be suspect, considering the above ... is that leaving out the UUID is the equvalant of

GUID( GENERATE-UUID )

For reference, base64-encode(generate-uuid) produces a case-sensitive string 24 long, hex-encode( generate-uuid ) produces a non-case-sensitive string 32 long and a simple GUID produces a non-case-sensitive string 36 long, apparently because of the addition of four dashes in fixed locations.

I would like to hear some official response to Mark Opfer's claim that using one of these three is insufficient if multiple machines is involved.  This seems rather important!

Posted by OctavioOlguin on 04-May-2015 12:49

Yes... indeed..

When working with this thread back then, I noticed also the bug in sintax description, but didn't reported here... As I recall I went to tech support to report it..  (at least i thought doing it)

And also, I found counter documentation the proof Mr. Opfer has found... That would be nice to dig into it...

Best Regards,

This thread is closed