Possible bug with hierarchical import ?

[eternalnomad]

Hi all,

I am new to Actinic and currently evaluating the "Actinic Developer" version.

I have been "ripping my hair out" for several days I think I may have discovered a bug and which I can reproduce on my own PC even using an export file created from within Actinic itself

I am importing a hierarchical file with each product in its own section and a duplicate product in the parent section of the real product (exactly like described in the knowledge base article http://knowledge.actinic.com/users/k...re.html#aCD526)

When I import my file for the first time - everything is as it should be, ie the products sitting in their own section and the duplicates in the "parent" - all the prices etc all are fine and the world is a wonderful place !

I then delete all the items and purge them from the database using Housekeeping -> Purge -> Purge content

The I try the import again using the SAME file and it :-

a) generates hundred of errors for "The price property is a duplicate"
b) All sections and subsections do import OK..
HOWEVER ....
c) None of the product duplicates are imported
d) None of the products are imported

I can repeat the "delete everything" -> purge multiple times and still get the same problems every time

However, (and this is the workaround) if I delete all the items, purge and then select Housekeeping -> Compact Databases -> Catalog

I can then import the same file with no problems at all

I think this is a bug - can any of you guys reproduce this problem ?

If I am doing something stupid then I would like to know what i am doing wrong.

If it is a bug then I thought it prudent to place on this forum to save others the frustration and days of "pain" wandering what is "wrong" with their hierarchical import files

Eternalnomad

[wjcampbe]

It is a 'feature' of Access that deletions are not 'really' deleted until a compact database operation takes place. That is why I recommend a compact before and after any major product changes.

[eternalnomad]

thanks Bill,

I must admit that most of my development experience in the past has been with "heavy iron" systems like SAP and Oracle.

However, I have used Access (and am actually using it now for my intermediate "middleware" database that ultimately will "feed" the Actinic catalo)

I have never seen deleted records fail to actually delete in Access and require a db compact

If Actinic are using ADO to drive the database and are caching the db tables then this could explain it

ACTINICSUPPORT - is this a documented bug with MS Access or a possible bug with Actinic

[wjcampbe]

From http://support.microsoft.com/default...b;en-us;283849

Description of the Compact and Repair Utility
Compacting a database
When you compact a database, the compact process will reclaim unused space in a database that is created by object and record deletions. It does so by creating a new destination database and by copying each object in the old database to the new database. If you choose to compact the database into the original database name instead of to a new database, the compact process creates a temporary database, exports all the objects from the original database into the temporary database, removes the original database, and then renames the temporary database to the name of the original database.

The following is a list of actions that the compact process performs:
• It reorganizes the pages of a table so that they reside in adjacent database pages. This improves performance because the table is no longer fragmented across the database.
• It reclaims unused space that is created by object and record deletions. When objects or records are deleted from the database, the space they occupied is marked as available for new additions to the database. However, the size of the database never shrinks unless you compact the database. For databases in which objects and records are frequently added, deleted, and updated, you should compact frequently.

To me this means the old data remains in place until a new record claims the space 'marked' empty, or until you do a compact. Perhaps my understanding is flawed.

[eternalnomad]

Hi Bill,

In this respect, Access is behaving exactly like every other database product (even the enterprise class, very expensive products e.g Oracle) - in the case of Oracle the equivalent process to a "compact" is known as a "re-org"

In other words - the compact/re-org process purely reclaims unused physical space in the .mdb file but is not related to the definition of if a record is deleted or not deleted.

What I suspect is happening is that ACTINIC is caching some of its database reads and/or writes (very common practice done for performance reasons...I even use it on my own middleware app.) and is not properly flushing the read/write function - hence the flakey status of the import into the catalog.

I truly believe this is a fundamental bug in ACTNIC catalog import and would like one of the ACTINIC support guys to comment.

Having said all that - I must admit to being highly impressed with the ACTINIC functionality so am pretty sure to be placing an order for the DEVELOP version.

[wjcampbe]

In this respect, Access is behaving exactly like every other database product

Indeed, and the only ones that were ever honest, and surfaced what was going on to programmer control were dBASE and its derivatives.

However I remain unconvinced that leaving data in place, which Access definitely does and changing the state of a memory allocation pointer, which Access uses as its 'delete' method can be described as an ACTINIC bug.

As Microsoft state, the correct thing to do is to compact your databases on a regular basis, and Actinic have surfaced that ability within their program interface.

I am sure the developers are aware that there are better database solutions and are working towards implementing one (or more). There have been definite hints dropped in these fora, that SQL based, platform independent backend database solutions have been and are being evaluated.