I'm working with a customer who has a document management integration with their case management system. The plan is to migrate all the legacy content over to Laserfiche. The current integration is fairly simple but is driven by the documentID's from the legacy system. Those numbers stop at 499877. If I could start the Laserfiche entryID's at 499878 it would make everything pretty straightforward. I know the tocid column in the toc table is an Identity Spec column that starts at 1 and is incremented by 1 and I know how to change it via sql but I would have to drop and recreate the table and I don't really want to risk that, even though this will be a brand new repository. Does anyone have any suggestions on how I could go about this? Creating empty documents and deleting them via workflow will be my last resort but that would take forever so any help is appreciated.
Question
Question
Is there a way to pad the tocid or entryID for a repository so that the next entry that gets created gets an entryID of 500000?
Replies
However, i'm not sure if this will accomplish what you want because you can't choose the tocid for the entries coming from the other system. Are you trying to avoid overlapping IDs between the old and new system? e.g. if you get an ID 12345 you want to know whether to look in Laserfiche or the old system?
Robert, you have the use case exactly right. I want to avoid overlapping ID's and their legacy system's last entry is just under 500000. If I can seed the tocid then I will not have to do much with their legacy files. Thanks for the response
My first question would be what's the end goal? Are you transferring documents from the legacy system, because if so, they'll get Entry Ids that don't match the identifiers from the old system anyway.
When we transferred documents from our old system into Laserfiche, we stored the legacy identifier in a metadata field, then we changed our case management system to reference the Entry Id instead.
To address legacy documents, we exported data matching old identifiers to the new Entry Ids and used that to update the storage information in our case management system.
During the transition, we had a storage type flag in the case management system that identified how the document should be referenced; if it was referenced by LF Entry Id it our API did a direct retrieval, if it was referencing a legacy identifier, it would run a search on that field.
Thanks for the response. yes, I'll be transferring those legacy docs into LF and I understand that they will get new entryID's. I was just trying to avoid having to "rekey" all of them. I've done pretty much what you describe in the past, I'm just trying to save a little time and re-seeding the tocid will help me.