> BTW as it comes over and over, I will do a FAQ for that...
>
> Jacques
>
> From: "Jacques Le Roux" <
[hidden email]>
>> Just be curious ;o)
>>
>> From
http://docs.ofbiz.org/download/attachments/4369/AdvancedFrameworkTranscription20060824.pdf>>
>> So unlike a package that each entity fits in one and only
>> one of the groups are a data structure, rather than a
>> configuration file we can use to group an arbitrary set of
>> entities. Each group will have an ID and a name. In
>> the entity reference pages we do see the timestamps
>> that the entity engine automatically maintains for all
>> entities, unless you use the attribute we talked about in
>> the entity definitions to turn it off. But by default all entities
>> will have these four fields; lastUpdatedStamp, lastUpdatedTxStamp
>> (transaction), createdStamp, and
>> createdTxStamp..
>> The transaction stamps are when the transaction was
>> begun that the change is part of, and the stamps are
>> within that transaction, although they are an absolute
>> value. But to order the actual records that changed
>> within the transaction.
>> Okay and the entity engine does do things for these
>> stamp fields when it maintains them, by the way, that
>> ensure that within a transaction each updated or created
>> stamp, depending on whether it's a create or updated,
>> is unique for that transaction.
>> So it'll keep track of the last one and always increment
>> it by one, even if it's been less than a millisecond since
>> the other record went through. As long as you don't
>> have more than a thousand records going into the database
>> per second in a single transaction then you
>> shouldn't have problems with overflowing it too much.
>> But it is important that those are unique, so we can
>> order all the records by these stamps and basically
>> reproduce the transaction to send it over to the other
>> server. Even reproducing the transaction we can't always
>> eliminate problems with foreign keys, but we'll talk
>> about that in a bit. Anyway that's the intention here, to
>> reduce problems with foreign keys as much as possible
>> and recreate the data changes on the remote server
>> when the synchronization goes through
>>
>> Remember : OFBiz was well thought out ! Be confident...
>>
>> Jacques
>>
>>
>> From: "Jacek Wagner" <
[hidden email]>
>>> BJ Freeman wrote:
>>>> that is transaction, like in updating data.
>>>>
>>>> BJ Freeman sent the following on 8/27/2008 2:52 PM:
>>>>
>>>>> TX stands for transaction
>>>>> you will note the LAST_UPDATED_STAMP is different also before you run
>>>>> the service
>>>>>
>>>>> Jacek Wagner sent the following on 8/27/2008 2:39 PM:
>>>>>
>>>>>> What is a purpose for having two (2) last updated datetimes
>>>>>> (LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP). Every time I run a service
>>>>>> (any) those stamps are one or two seconds apart.
>>>>>>
>>>>>> Curious Jacek
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> Can you present a case where only LAST_UPDATED_STAMP or
>>> LAST_UPDATED_TX_STAMP will be updated.
>>>
Locked
