>What I haven't tested is replacing the entire path. However, if replacing
>the drive works, it would seem logical that replacing the entire path would
>work as well. My guess here is that the binary data in the field has
>nothing to do with where the file is located. Admittedly, this test was run
>by creating another mapping to the same server. This means that the same
>table was being accessed. I have no idea if number records, last update or
>anything else would change the binary data in the field.
I've been experimenting with the property field, and it seems to keep
all the strings with some binary header and footer, so if you know
exactly what to remove or change, you only have to take care to put
these binaries where they were. The easiest way to find what's the
header and what's the footer was to hex dump the property field, copy it
to a file, remove a property, dump again, re-add the property, dump
again. I've done it with the PK, and found what bytes were moved to the
end of the memo. The conclusion I came to is that it only matters that
you have the property string surrounded with a proper header and footer,
and its position is irrelevant (in the third dump the PK was at the end,
while in the first it was the second property, and missing altogether in
the second). So, Repl property with StrTran(property,
"old\path","new\path") shouldn't change a thing (except the path, of
course :).