>Did any of the tables being copied already exist in the destination? Copying will fail if the destination table already exists.
No, each time i tried this i created a virgin database on the destination machine.
>What if you do one table at a time using -t?
Since there was almost 70 tables to copy, i thought it might be a little time consuming doing each table manually. The task of re-creating all the indexes is daunting enough.
Does it always get stuck at the same place in the same table? Does it copy part of that table or none? What if you try just that table by itself? What's the schema for that table?
It looks like its getting stuck after copying one row of a table called blobject. The only really unique thing about the table is that it has blob field for holding large binary junk. Since the last modified file on the destination machine was the ".blb" file that belongs to that table, i assume that the prob was caused by that field.
Heres the schema:
tsql "select * from SYSCOLUMNS where TBNAME='blobject'"
Texis Version 05.01.1109947850(20050304) Copyright (c) 1988-2005 Thunderstone EPI
It appears to be a problem with blobs in the -64-64 version. We're looking into causes. I don't have any workarounds at the moment except to export, transfer, and reimport the data.
