XP SP2 problem

XP SP2 problem

Post by Jure » Sat, 03 Jun 2006 01:03:33


Rows addes on XP SP2 machine wont replicate to other databases, they have
nulls in s_Generation column.
Is there a cure for this?
 
 
 

XP SP2 problem

Post by David W. F » Sat, 03 Jun 2006 05:45:16

"Jure" < XXXX@XXXXX.COM > wrote in



Newly added rows should be generation 0.

Are you saying that when you manually add a record to a table in
datasheet view, the s_Generation column remains Null?

Sounds like a major corruption of some sort.

--
David W. Fenton http://www.yqcomputer.com/
usenet at dfenton dot com http://www.yqcomputer.com/

 
 
 

XP SP2 problem

Post by Jure » Sun, 04 Jun 2006 01:36:40


I solved the problem. I use ADO and server side cursor to write changes in
database and during this process I initialize s_Generation column to null
because this is a generic procedure that copies values from my data storage
to recordset. On windows other than XP SP2 it works just fine but on XP SP2
null value is actually written in database. I can only say to good people in
Microsoft: don't fix it if it's not broken :))))
 
 
 

XP SP2 problem

Post by David W. F » Sun, 04 Jun 2006 02:43:59

"Jure" < XXXX@XXXXX.COM > wrote in






I didn't know you could edit data in the s_Generation field. It's a
Jet replication field, and I thought was completely unavailable for
any manipulation at all.

--
David W. Fenton http://www.yqcomputer.com/
usenet at dfenton dot com http://www.yqcomputer.com/
 
 
 

XP SP2 problem

Post by Jure » Sun, 04 Jun 2006 06:35:29


No, I didn't edit it, I created a new row, passed null through ADO as
initial value (before calling Update method) and database accepted it
instead of putting zero. I did the same for other replication fields (s_GUID
and others) but they are initialized correctly.
 
 
 

XP SP2 problem

Post by David W. F » Sun, 04 Jun 2006 06:46:43

"Jure" < XXXX@XXXXX.COM > wrote in








Why in the world would you do that?

I would surmise that they are just like Autonumber fields, but if
you want the values in them to be correct, why would you pass a Null
as the value? The fields will initialize themselves correctly if you
don't pass any value to be appended into that field, so why would
you be mucking around with inserting values that are of no concern
to you?

--
David W. Fenton http://www.yqcomputer.com/
usenet at dfenton dot com http://www.yqcomputer.com/
 
 
 

XP SP2 problem

Post by Jure » Sun, 04 Jun 2006 16:42:35

David W. Fenton" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

We can argue what is wrong and what is right but I still think that
autonumber/system/read-only column shouldn't get confused when you try to
initialize it with some value. It should ignore it and preserve data
integriti. I keep my data in my own data structure and use server side
recordset for update. This way I have all then benefits as if I use client
side cursor and the update speed of server side cursors (update of client
side recordset is much slower) plus correct handling of transactions
(Rollback transaction won't work with client side recordsets, they won't
update correctly next time). So, when I add a new row I call ADO's method
AddNew and pass array with names of all the columns and array with all the
values. Second array has null value for s_Generation column and it is a
problen on XP SP2 machines.


 
 
 

XP SP2 problem

Post by David W. F » Mon, 05 Jun 2006 05:55:42

"Jure" < XXXX@XXXXX.COM > wrote in



Well, that's a mistaken idea of what an Autonumber field is. It's
not an identity field, but just a long number with a special kind of
default value.

I do agree that replication fields oughtn't be writable, yes, and
was surprised that s_Generation could be appended to.


Well, your mistake is in passing a value for a column that you agree
you shouldn't be messing with. If it worked the way you assumed, it
would have thrown an error.

Now, I don't know why different computers (perhaps with different
versions of ADO?) gave you different results, but the situation is
one where you shouldn't have been assigning a value in the first
place, regardless of how ADO behaved, so the mistake was yours, a
conceptual mistake, not a problem with ADO or Jet.

--
David W. Fenton http://www.yqcomputer.com/
usenet at dfenton dot com http://www.yqcomputer.com/