>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 :).