In which cases the Handle is not persistent?

[Anonymous]

I have an application that saves the handle of some geometry on a DB.

The geometry is limked with database information, and each time the drawing is open the data is loaded to application via a Handle.

I used the Handle, because the is persistent, but one time when I open the drawing, the applications says the data doesn't match the drawing, I check it and it was the same drawing, when defining again the geometry I realize the handle had change.

I don't know why this happens, I only save and close the drawing. Is there some point the handles need to be recycled on the application?

Or what could happen that changed the handlers of the drawing.

It only happen one time, in one drawing, but I don't know if it can happen again.

Thanks

[hgasty1001]

Hi,

To my knowledge, handles are always persistent inside the same drawing, maybe someone (a program or a person) is replacing unintentionally (or not) the original entity with a brand new one, with the exact same data, a second chance: maybe are duplicates overlapping and the application is handling the wrong one.

Please let us know the progress of this issue as it's a very extrange behavior.

Gaston Nunez

[Anonymous]

Hi

There wasn't other geometry, because the program was loaded one time successfully, but the second time that was loaded, the Handlers where different I thought it was a different drawing but the user says it was the same.

We had to reset the application to start defining again, once the drawing was saved on the DB we run again the program and the data was saved normally and now its loading fine, I couldn't see what happen but I was wondering if anyone had a similar case.

It's really weird it only happens with one drawing, and happen when closing AutoCAD and reopened the drawing.

Thanks for the reply

[dgorsman]

Consider that users don't always report what they have actually done e.g. restore DWG from backup, WBLOCK out most (but not all) contents, COPYPASTE into a blank drawing, and so on.

If these are not standard AutoCAD entities (ie. line, circle, block, etc.) and vertical or third-party tools are involved, then making changes to certain drawing entities may very well be replacing them instead of editing, which will result in new handles for nearly identical objects.

[Anonymous]

Hi, I told the user to save a backup from the drawing before starting to use the application. In theory the drawing must be finished, the plugin only classified three kinds of geometry and upload it to their database by handle. Once the geometry is connected the user can make database operation and show in the drawing, the app doesn't draw or erase geometry.

I'll keep an eye in the drawings to see if the user make something strange, also I'm going to keep it open if that happen again

Thanks, for the Help.

[Anonymous]

"...restore DWG from backup..." Do you mean handles are reassigned when a DWG is restored from backup? I tried testing it, but could not damage the file enough for it to have errors while remaining recoverable. So, if I was to rely on handles, I would have to disable the recovery feature? I'm working on a project that requires linking database with entities in DWG too, and am looking for some property to uniquely identify the entity in the file for that entity's entire life span. Would handles be considered persistent enough for this role at all?

[Anonymous]

Hi,

The Handles from what I know are persistent, but the user might copy paste the geometry, or modified it with other tools to update the drawing. So one solution that works for me was to make a back up, before connecting the geometry to DB, to ensure there will be no changes on the Handles.

What I didn't want to do was to save in the extension dictionary my own id, because of the final size of the drawing, but that might work for you.

Best Regards

[Anonymous]

I see, thanks for the answer.

I think copy-paste can be controlled by storing entity's own handle and a file name (or file identity) in XData or extension dictionary, as described in this post.

I am currently storing SQL IDs inside entities, but would like to move away from it, as the process is very clumsy.

As for size concerns, I've stored entire serialized object hierarchies in Xrecords ("no external database" was a requirement) and increase was barely noticeable, especially compared to some 20 MB monster files we receive from our partners sometimes.

[dgorsman]

A very simple example.  The drawing has three lines in it, handles "A" "B" and "C".  The user adds a fourth line which is assigned handle "D".  Something causes the drawing to be corrupt, or maybe somebody permanently deletes the file.  So the user gets a backup of the drawing which was from before the fourth line was added - there is no handle "D".  The user adds a circle this time instead of a line, and it is assigned handle "D".  Then they add the line, which is assigned handle "E".  The database is pointing at handle "D", but that handle is actually a circle while the database still thinks its a line.

The above is a good reason why there should be a DB verification/reconcilation function in the application which can cross-check the drawing contents against the database.  Typical outcome is to mark all non-matching records in the database for deletion and add additional records for drawing objects not in the database; or, failing that rebuild the database from scratch (at least for that drawing file).

[hgasty1001]

Hi,

Try activating the log in options, so you can do a forensic analysis. Let us know your findings.

Gaston Nunez

[CADbloke]

An edge case but an example of what can happen: you can use DBObject.SwapIdWith() to swap handles (I assume since objectIds are not persistent across sessions) between objects. For an example of this see http://through-the-interface.typepad.com/through_the_interface/2010/07/swapping-autocad-block-attrib...

If my assumption that DBObject.SwapIdWith() swaps handles is wrong please let me know.

[Anonymous]

DBObject.SwapIdWith() swaps both ObjectId and handles. Furthermore, it can swap Xdata and extension dictionary if second and third parameters are true.

Which probably means that no kind of linking mechanism is safe from unscrupulous developers using SwapIdWith(newId, true, true) on your object. I don't know if it's a good or bad thing, but the object being pointed at from DB (or the object pointing at DB record) will not be the same in this scenario.

[Balaji_Ram]

Hi,

I am not sure if this is the reason for the handle to change in your drawing, but handle value can get modified by AutoCAD although they will continue to be unique in the database.

One such example is during a block edit using the BEDIT command. It can change the handle of an entity in that block.

Regards,

Balaji