On Fri, Oct 3, 2008 at 11:56 AM, MB Software Solutions General Account
<[EMAIL PROTECTED]> wrote:
> On Fri, October 3, 2008 12:33 pm, Stephen Russell wrote:
>> In reality, what are you getting in a refresh?
>> 1) any updates done while this data was brought local.
>> 2) secondary data refresh for inventory count >0
>> 3) some other reason?
>>
>>
>>> From that reply you have to design how you want to handle the
>>> situation.
>> for #1 attempt your update as dynamic SQL to only update row(s) because
>> the same starting data exists for the overwrite against the dataset you
>> currently have.
>
> That's why the timestamp field is great in some RDBMSes...that allows you
> to get the records that have been updated since the last time or avoid
> just slinging the same data back and forth.  Surely don't commit changes
> to data you didn't change (like blind updates).
------------------------------------------------------------------------------------------
I have to disagree on a timestamp for that use.

If I pulled a row of data and want to update it, and nobody else has
updated that column of the row, I should have full clearance to write
that change back.

I could be on the phone with a customer and changing the contact
person's name in the cust table at the same time the end of month
could be running anf for sume reason it updates the cust table with
Lastmonths Order Value.  Why should that update interfere with mine?
Your timestamp clause would screw over my update.




>>
>> So you build up the list of columns to apply your change(s) to and
>> then run it.  If you get a count back >0 for rows changed great. Otherwise
>> someone beat you to an edit.
>
> Right
>
>>
>> For a #2 you have to just query that your count of existing ??? is
>> still available before you write the row.
>
> I don't follow you on that one.
>
>
>
>
[excessive quoting removed by server]

_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to