GUID format different between DAPINODE and Oracle version of DTree

Hi,
I had an override in the Item Handler code (for product integration) where I need to get the category ID. The definition fragment passed into MapWFDataToCat() has all the information about the category including it's GUID except no category ID. So I wrote a small routine to fetch it from the GUID. In SQL Server, no problem. The GUID stored in the attribute definition (which comes directly from the DAPINode object) matches perfectly. However in Oracle, not so. In Oracle, if I have a GUID in DTree that looks like this:
FC147042998547079A2B26CFB9540773

the corresponding DAPI NODE will return this as its pGUID feature which is what gets copied into the attribute definitions GUID feature:
FC147042-9985-4707-9A2B-26CFB9540773

In Oracle is there a way to reconcile these besides stripping out the dashes? I would like to have just one function for all db vendors.
My Workaround was that I found that the auditInfo assoc passed in as another arg to the same function had the catID right there, but I don't know if it's universally going to always be there.
-Hugh

Find more posts tagged with

Comments

John Simon

Is regex be an option?
Cheers...

Appu Nair

Most sites like Stackoverflow are pointing to what @John Simon is alluding. Looks to me in SQlserver it is a datatype. Oracle does not have an equivalent see this posting
https://stackoverflow.com/questions/153815/how-should-i-store-a-guid-in-oracle

SELECT SYS_GUID() FROM DUAL;

SELECT GET_FORMATTED_GUID() FROM DUAL ;

perhaps there are already things in the DBWizAPI or CAPI layer that can help ?

HFCDev

I suspect if there is an equivalent to GET_FORMATTED_GUID() in the code-base, it's probably buried deep in the DAPI Drop-in source which we don't have access to.
Two reasons for my workaround:
1) Have something that works regardless of the db,
2) Using auditInfo.CatID, I'm saving myself a trip to the database.

I would like to hear from OT if there will be a core function like the GET_FORMATTED_GUID() that would be available to developers so we can get GUID that matches regardless of the db vendor. I don't know what the other DBs store which is why I would like it if I can always get the GUID in the format that the db vendor uses.
-Hugh

HFCDev

I did find out a few interesting things when I played around with this. First, the actual pGUID feature on the DAPINode is actually a data type called GUID. However, within an attrData object, that pGUID is stringified into the assoc (probably so that it can be stored more easily in the LLCache table). Second, if you take that string from attrData.GUID and strip out the dashes, it will patch the GUID field in DTree. So that's handy.
Cheers
-Hugh