We have encountered an issue using our database. the last few times we haven't had any issues, but recently a re-occuring issue of components taking on other components descriptions after the model is re-synced.

Now we do modify our Access databaes to make global changes to long and short descriptions via the find/replace tool. But only recently have we had this long description swap.

My first thought is that it was user error and that cells were shifted creating this BAD sync. but after re-creating the database and working on it down the road the issue re-surfaced.

Has anyone delt with this issue or have any ideas as to its origin?

Thanks!

WAG - somebody copy/pasted components from another model?

No, thats not the case. The troubling issue is that we've used databases in the past with no issues, in fact the same user had issues

Just a caution when doing a search and replace. The key for CADWorx to tie the information to the Database and the drawing is the Autocad handle. So if the handle contained the sequence of the search and replace it would get changed. And this could allow some entities to be dropped from the database since they no longer reside in the drawing based off the Autocad handle. Then it could make another handle grab the wrong object if it's handle was changed to a valid handle.

Just throwing this out there and maybe it is a valid point maybe not.

Thanks,

Are you trying to use ACCESS on a network with multiple users? I have seen that make some major corruptions.

If you are using ACCESS as a network database, I would suggest that you transfer to SQL and use ACCESS as a front end.

We have used Access databases and multiple users for some time without issue. Switching to SQL Server adds a whole new level of administrative, hardware, and tech support issues. IMHO the advantages don't outweight the disadvantages unless the projects are very complex and/or have a high data turn-over.

IMHO, wow I am going to have to use that accronym.

dgorsman: I don't know how you managed a multi-user dbase in Access, but congrats.

We had nothing but problems since there were multiple users in the database at the same time. It caused a lot of corruption and downtime because of it. It was also very slow over a network (multi-office). This is why we went to SQL. Yes there is an administrative part to it, but worth the savings in downtime.

OK, yeah - multi-office database is very difficult to get going even when using SQL Server.