On 7 Oct 2009, at 10:13am, Jean-Denis Muys wrote:
> [setup description]
>
> I'd appreciate some feedback here or
> pointers to litterature.
You see how complicated you had to get before you had an acceptable
solution ? Two extra columns ? Timestamps ? Retention of records
which have to be
On 10/7/09 11:50 , "Simon Slavin" wrote:
>
> On 7 Oct 2009, at 10:13am, Jean-Denis Muys wrote:
>
>> [setup description]
>>
>> I'd appreciate some feedback here or
>> pointers to litterature.
> Try really really hard just to have all sites access your MySQL
> database remotely.
Unfortunately
On 7 Oct 2009, at 1:47pm, Jean-Denis Muys wrote:
> On 10/7/09 11:50 , "Simon Slavin" wrote:
>
>> Try really really hard just to have all sites access your MySQL
>> database remotely.
>
> Unfortunately this approach is not possible in the short term. The
> client
> applications are legacy appli
regarding this
" The fault is that
almost nobody does it right: they neglect to keep an 'unaltered
central copy' and think they can cross-apply journals each time two
databases talk to one-another. That does not work for various reasons."
Would a central repository of journals that can be applied
On 7 Oct 2009, at 7:20pm, Adam DeVita wrote:
> regarding this
> " The fault is that
> almost nobody does it right: they neglect to keep an 'unaltered
> central copy' and think they can cross-apply journals each time two
> databases talk to one-another. That does not work for various
> reasons.
Simon Slavin wrote:
> On 7 Oct 2009, at 7:20pm, Adam DeVita wrote:
>
>
>> regarding this
>> " The fault is that
>> almost nobody does it right: they neglect to keep an 'unaltered
>> central copy' and think they can cross-apply journals each time two
>> databases talk to one-another. That does n
"You have to be really careful"
Absolutely. Even if you know the order of updates (which I do). If site A
updates an off line record in a cached copy after site B deletes it other
sites can receive the change records in order and have the record re-appear
(via insert or replace).
One can also g
On 7 Oct 2009, at 8:33pm, John Elrick wrote:
> Isn't this a variation of the DVCS problem? In other words, would it
> be correct in saying that the underlying issue is treating this as a
> database problem, rather than it being a versioning problem which
> happens to involve a database?
Yes ye
Simon Slavin wrote:
> On 7 Oct 2009, at 8:33pm, John Elrick wrote:
>
>
>> Isn't this a variation of the DVCS problem? In other words, would it
>> be correct in saying that the underlying issue is treating this as a
>> database problem, rather than it being a versioning problem which
>> happens
On 10/7/09 21:35 , "Adam DeVita" wrote:
> One can also get a mess if Mr. Red and Mr Black both get new customers, and
> enter them and they both get the same ID because the auto-generated int
> happens to be the same. Both copies get updated with the other guy's data,
> they then get annoyed and
Jean-Denis Muys wrote:
> On 10/7/09 21:35 , "Adam DeVita" wrote:
>
>
>> One can also get a mess if Mr. Red and Mr Black both get new customers, and
>> enter them and they both get the same ID because the auto-generated int
>> happens to be the same. Both copies get updated with the other guy's
11 matches
Mail list logo
