7/8/2025 6:32:39 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
|
|
|
|
Database Merging
Posted: 03 Mar 10 12:00 PM
|
Hi,
I am just wondering if there is a third-party tool out there that will merge 2 saleslogix databases. If not, is there somewhere or someone that may have done this? I'd like to know how challenging of a task it is and if there are any internal methods I can use to do this.
Thanks |
|
|
|
Re: Database Merging
Posted: 03 Mar 10 2:46 PM
|
Taking aside Data Deduplication and Schema differences, the process could be quite simple.
Each SLX Database has a Site Code, which is used to generate IDs. Many people leave it alone, so most Host Databases share the 6UJ9 site code. Also, if the Database to be Merged had Remote users, there may be other SiteCodes involved. The first phase would be to locate those Site Codes, replace them with Unique site Codes different from the ones being utilized on the Target Database.
From there on, bring the data over means just copying the Data across.
Once that is done, you may still need to replace User and Team references. I guess it is possible to Copy Teams and Users as well (using the same approach listed above), and just update those IDs as well. From there on, it becomes an issue of active References (e.g. migrated users are all set to "Retired", and then update Acct. Managers and Teams to match the Ownership rules on the newly merged Database.
Now, I may have oversimplified the tasks, but again, if you are careful around IDs and cross references you should be good to go.
Alternatively, you could generate new IDs for all records as needed by using the OLEDB Provider (or similar to generate IDS).... Your choice, just remember to keep a way to reference your data back for proper linking after the fact.
|
|
|
|
Re: Database Merging
Posted: 04 Mar 10 2:58 PM
|
We've built a SSIS job which does exactly that. The data can go one way or be bi-directional. Quite a few hours have gone into make this work. While on the surface it may seem a simple task to simply merge data there are a lot little gotchas like id collisions, record ownership, merging one userid into one or more others, UTC date/times, referential integrity etc.
Currently our SSIS support the following
Cross Mapping of:
USERS
SECCODES
PRODUCTS
Table Merging
- ACCOUNT
- ADDRESS (Account)
- CONTACT
- ADDRESS (Contact)
- ASSETS
- CONTRACTS
- TICKET ACTIVITY RATES
- TICKETS
- TICKETACTIVITY
- HISTORY (account, contact and ticket)
- ATTACHMENTS (account, contact, and ticket)
One area we haven't built is opportunity related information but I think would be a snap if you need that too.
One of the big pluses with this approach is that you rarely get the migration perfect on the first run and because the SSIS job maintain xreferences for all data you can run it over and over again while your live (yes it uses the slx provider so that data synchronizes to remotes) till you're sure you've got everything you need (i.e. custom tables, fields, etc).
Let me know if you would be interested in using our solution.
James Sutton.
|
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|