tbunload/load bugs in OnLine 5.0???

11.22.1992 This weekend I ran into what appears to be a couple of bad bugs with the tbunload/tbload utilities of OnLine 5.0. I was wondering if anyone else has seen the same thing. problem 1: I had a table containing a blob column in its schema that I needed to move to another dbspace. The blobs (type text) are stored in a blobspace. According to the 5.0 Administrators Guide (OAG), if you tbunload/load a table containing blobs, and those blobs were stored in a blobspace, when the table is re-loaded, you'll be prompted as to whether or not you want to change blobspace for storing the blob. As I only have one blobspace,I didn't see the prompt. The table unloaded without any errors and apparently loaded without a problem . When I went to grant permissions on the table under dbaccess, I got errors back indicating an inability to access the table. I pulled the table up via info and the engine showed it there, with columns, but no rows. I ran a dbschema from the command line and got an error back indicating the table could not be accessed. I guess you can't tbunload/load tables with blobs. problem 2: I set up a foreign key constraint on a single column within a table. I needed to move this table to another dbspace. Again the tbunload/load ran fine. There weren't any blobs in this table so the rows came across without any problem. The problem arose when I realized that the foreign key constraint was partially corrupted. The index on the table created by the engine during the constraint creation was still there but there wasn't an entry in the sysconstraints table. I tried to just recreate the constraint but I got an error back saying the index already existed on the column. Because of the format of the index name created by the engine during constraint creation (a space in the first position of the index name) I couldn't drop the index from dbaccess. Deleting the row from the sysindexes table corrupted the sysindexes table-- dumb thing to try I know but I was screwed already and would have to restore from archive so why not try. basically I'm stuck with an index I can't drop and a critical business rule I can't enforce. Any ideas on either of these two problems?? I'd appreciate any e-mailed insight. Thanks in advance. In case it matters, I'm running on an AT&T StarServer E running Sys V Rel 4, ver 2.1 ------------------------------------------------------------- Carlton Doe cdoe@sunset.utah.edu attmail: attmail!alexis!carlton