unique id - help please !!!

Use the iwattrib.exe command line tool to get the objid of the document. It is unique to that document in its original workarea. After submission to staging,however, the staging area copy gets a different objid. You might want to set and extended attribute with the original objid value so you can refer to it later from the staging and/or other areas.

You might try:
iwattrib objectvpath objid
Caveat: The value returned for the objid will be different in each workarea and distinct in the staging area from that in the workarea too - even if the files are otherwise identical - so as long as you are using the same reference area you should be okay - otherwise you need a different solution.

The objid looks like 0x000010083d5bf6bb400000fa

hope that helps

--fish
(Interwoven, Curriculum Development)

james1

FYI: I think that if you take just the last 8 digits of the objid, then the objid will be constant across areas, but still unique for all versions of all files in that store. However, given those 8 digits, you will not be able to retrieve a copy of that file from TeamSite -- you need a complete objid for that.

-- James

--
James H Koh
Interwoven Engineering

James/ALL-

Could you explain how the objid is generated? Are they like Microsoft GUIDs where part of the ID is based on the NIC ID in the server so each ID generated is totally unique?

I'm saving the objid of a DCR as an extended attribute that is later used as an ID when interfacing to a Siebel CRM application. I'm concerned about what might happen if/when I have to migrate to a different box. Is it possible / probable / unlikely that the new TS server would generate an objid already in use (generated by the previous TS server before the migration)?

THANKS in advance....

This seems to be off-topic in Templating so I re-posted my question in Content Management....

I'm faced with a similar problem in that I need to create a unique identifier that will be stored in the XML for my data record (the identifier will be used later when the XML data is stored in a separate database). So, when a new data record is saved, this unique key will be stored, and it will never be changed.

I've been trying to come up with a way to generate this unique key, using some old standards such as date or time or user name, but the idea of grabbing the objid sounds intriguing.

If I grab the objid when the DCR is created, and store it in the XML, then no matter where that data record gets copied (other workareas or staging), that same value will still be in the XML, and will still be used as an identifier.

Here's my question: Is there any way another data record ANYwhere on my TS server will be created again using the same objid? If so, I won't be able to use it as a key.

I'm running TS 5.5 on AIX. Any help would be appreciated!

--Sandra

Migrateduser

What DB are you running - I'm generating unique_ids in Oracle using an inline_perl script - the unique_id field
is hidden on the DCT - and remains state so that each time a
user edits that file - the id isn't incremented. This has been working great for several months now - all data get's saved in the Database. Also, as a side note: I have the db config set-up to use DAS

james1

> Is there any way another data record ANYwhere on my TS
> server will be created again using the same objid?

I don't think so.
-- James

--
James H Koh
Interwoven Engineering

Do not use TeamSite object ids for this purpose.

TeamSite object ids are an internal aspect of the TeamSite system and are not guaranteed to remain consistant across upgrades, restores, service packs, etc.

They are not, have not, and most likely will not ever be supported for the kind of functionality you are looking for.

Save yourself / your clients a load of grief, and do not use object ids for anything other than what they are documented for.

--fish
(Interwoven Senior Technical Consultant)
(PS: yes this is a deviation from my earlier response - based on more information having been learned since then)

Edited by ghoti on 02/06/03 08:18 AM (server time).

fish,
My project requirements state that I must have some sort of unique identifier associated with each XML file. I can construct this identifier from other means, but was merely looking for objid as a "random" yet "unique" way to idenfity it. I was in no way expecting the number to tie back into TeamSite's database at a later date, or to ever match up again with an objid or DCR instance. Based on that, are you still concerned with my use of this value?

Well based on your intended usage, the risk is minimized - but not completely removed. If you associate an XML file with 38383838 which happens to be it's TeamSite object id, and then you upgrade your TeamSite server - it is *possible* that you may create a new file which gets that same object id (becaue the old one now has a different object id) - and thus you would no longer have unique identifiers for your files.

So - yes, I have some concern, but it's your decision as to how likely you think this problem might occur.

--fish
(Interwoven Senior Technical Consultant)

I'm doing the same sort of thing. I "uniquify" the objid by prepending a timestamp. I associate it to the content item by saving the resulting ID as an extended attribute that accompanies the content through submittals, get latests, and migrations to other servers.

Incidentally, this approach was formally approved by Interwoven after running it past various engineering and tech support staff.

I was considering that exact thing -- prepending the date/time to the objid. Thanks for the confirmation of IW approval!

With the prepending of the date/time - the risk that I was talking about becomes virtually non-existant. Either you didn't mention it before, or I missed it in your description.

Without that additional semi-unique modifier the risks were present.

--fish
(Interwoven Senior Technical Consultant)