Database that ate New York - any official response?

[Kevin]

I'm still sitting here with a 2Gb ActinicCatalog.mdb which is the result of my copying and pasting components from one product into multiple (hundreds of) others. I know that's what caused it, because I did it twice. I just got off the phone with support who told me that they've never heard of this type of problem with Catalog before (whereas I'm sure I have, albeit with earlier versions), and that I should try using a different computer... Heh. Like that's going to happen...

I can't compact the DB from Catalog (which worked last time) because Catalog refuses to start ("! Invalid Argument"). I've tried Compact/Repair in Access 2000, which processes for a full five minutes but achieves nothing. I've reinstalled Catalog (6.13) twice on different partitions, upgraded MDAC drivers, but it still won't start.

So can anyone tell me where 2Gb of cruft might be hiding in an Access database? I have 3000-ish rows in the Product table, 200,000-ish rows in ProductProperties, and very little else. It's nothing even remotely resembling 2Gb of data.

[Ben]

Hi Kevin

I'm not sure if this is a bug in Actinic or a bug in Access. I've notified the development team and will let you know what they suggest.

Ben

[Kevin]

Thanks for the reply, Ben.

I don't know if this is any help, but I think it's likely to be a problem with Access. I've since attempted to delete a bunch of rows from ProductProperties (hoping to alleviate the load) and was quite amused to receive the same, uber-useful "! Invalid Argument" error that Catalog reports when it's trying to start.

[Kevin]

Forget it. I've binned the DB and am starting again, Access wouldn't even export the tables. For the record, I'm blaming Access for the whole sorry debacle.

[Ben]

Kevin

If you still have the database available, I've received some instructions for manually purging sections/products/components etc that have been marked for deletion. As always the recommendation is to backup the db first, but I guess it won't matter too much if you are planning to bin it.

Important: The purge will remove all sections and products marked for
deletion and is not reversible.

1- Open ActinicCatalog.mdb with Access 2000.
2- Select the Queries object.
3- Double click 'Create Query in Design view', the 'Show Table' window
will open.
4- Click Close.
5- From the menu bar, select View | SQL View.
6- Replace the contents of the SQL View window (SELECT with the SQL
statement in SQL_1 (see below).
7- From the menu bar, select View | Datasheet View, this will show which
and how many records will be purged.
8- From the menu bar, select View | SQL View.
9- From the menu bar, select Query | Run, this will execute the SQL
statement and prompt the user to confirm that the query is to be run and
that the records are to be deleted.
10- Repeat 6 through 9 for the SQL statements in SQL_2 and SQL_3.
11- From the menu bar, select Tools | Database Utilities | Compact and
Repair Database, this will recover the space freed by the deletions. If
prompted to save the Query, click No.
12- Close Acess.
12- Open Actinic.


SQL Statements, copy as is from 'DELETE through to ';'.
SQL_1/. Purge Product Components etc.

DELETE ProductProperties.sStatus, ProductProperties.*
FROM ProductProperties
WHERE (((ProductProperties.sStatus)="D"));

SQL_2/. Purge Products

DELETE Product.Status, Product.*
FROM Product
WHERE (((Product.Status)="D"));

SQL_3/. Purge Sections

DELETE [Catalog section].Status, [Catalog section].*
FROM [Catalog section]
WHERE ((([Catalog section].Status)="D"));

[Ben]

Possible explaination for the Access error ...
http://support.microsoft.com/default...ticle%3D302495

[Kevin]

Thanks Ben. I still have the backup DB so I'll try that 12-step plan (!). I had already tried installing SP1 but that didn't help.

If you want to try to recreate this for verification or whatever: I had a component, containing 3 attributes, containing 5, 14 and 11 choices. The component had 124 valid permutations of these choices. Pasting the component into multiple products caused the DB bloat. Pasting it a couple of hundred times was enough to max out the filesize of the Access DB at 2Gb. Catalog 6.13, under XP SP1.