'sdequery' is a custom command-line utility available within the se_toolkit suite (the link
for which was broken during transition).
I think you're mis-understanding the significance of a HIGH-precision coordinate reference.
There is no "single to double precision" conversion. ArcSDE has always represented
coordinate data in double precision, and that has not changed. The only change is that
previously, when coordinates were encoded in 32-bit integers (31 bits), now they are
encoded in 64-bit integers (54 bits [the size of a double mantissa]). This does not change
the precision of the data, since increasing available bits does not improve accuracy.
The only way to test if anything was lost is to do a rigorous regression test. One way
to do that would be to query each table (source and destination) with
sdequery -t tabname +DIGEST tabname.dig,KEY=keycol -N
The trick here is that you need a non-OBJECTID key column in each table. If you
preserve the objectid as 'origid' and eliminate the new rowid column from the column
list (-C flag) you could validate the row content, but only for simple feature classes --
ArcSDE API apps will not honor (or even see) relationship classes or feature datasets
or other ArcObjects behaviors.
In order to compare geometries between instances, you would need to utilize a
coordinate reference XYSCALE that was an even multiple of the previous scale
(if the old xyscale was 1000000, use 10000000 or 40000000, not 1111948722.22
or whatever the odd-ball value is used by default by Desktop), since the tiny
variance of division by xyscale will alter the double geometry extent (used by
the default PARTIAL comparison).
- V
