5/5/2024 1:31:15 PM
|
| |
| 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 general SalesLogix import and data migration topics. View the code of conduct for posting guidelines.
|
|
|
|
Merging Two SLX Databases into One...different version numbers
Posted: 17 Mar 06 6:23 PM
|
fiogf49gjkf0d I am having a difficult time coming up with an avatar for this cool new forum, however in the meantime I have come up with a fun scenario and was wondering if anyone cared to share their professional feedback.
The topic is focused on merging SalesLogix databases. Two into one to be exact. Imagine two divisions within one company are on a single 6.0 database and a third division is on a separate 6.2.1 database. The ultimate goal is to end up with one single 6.2.3 database.
At this point I know this involves a data conversion and an upgrade, both of which I am very compfortable with, however I am just not sure which order would be most advised.
Sparing any conversation around best business practices and how to setup security and segment the data once the end result has been acheived, can anyone make a recommendation on approach to this? In other words, would you migrate data and then upgrade, or would you upgrade both DBs to 6.2.3 separately and then merge into one, etc....or whatever? (I am personally a fan of "whatever" but we cant seem to sell that much these days).
Also, if you can make any suggestions on how best to merge the SalesLogix database (tools, methods, etc) and any pitfalls/gotchas one might need to consider (site keys), that would also be very helpful.
Happy St Pats!
Steve Korosy
MBSG |
|
|
| |
|
Re: Merging Two SLX Databases into One...different version numbers
Posted: 19 Mar 06 8:14 AM
|
contrave weight loss success naltrexone weight loss
What I would do is a very basic upgrade on the 6.0 databases to 6.2. Then use GroupCopy to import the All Accounts group (or other suitable group) into the 6.2.3 database.
If you have loads of data in custom tables, you could consider updating all the keys in the 1st source database to 1xxxxxxxxxxx instead of Qxxxxxxxxxxx and in the 2nd, updated to 2xxxxxxxxxxx. That way, you avoid the possiblity of key collission. You could just use DTS to pump this in then using a SQL connection.
Stephen
|
|
|
| |
| |
|
Re: Merging Two SLX Databases into One...different version numbers
Posted: 19 Mar 06 6:23 PM
|
fiogf49gjkf0d Maybe I always do things the hard way?!? The suggestion to use GroupCopy is a good idea, but I've never gone that route before. I usually just upgrade one, recreate users and import. I'm not sure how groupcopy would handle the ownership of records and any userid's from the other database.
BTW, do you also have to migrate customizations from one to the other?
I usually do something like this (We'll call the databases db1 and db2):
1) Pick one to be the master, this will be db1. The other we'll migrate to that one, this will now be db2.
2) Upgrade db1. Leave db2 as is (unless required to create bundle of customizations)
3) Bundle and tables/customizations/groups/etc from db2 and install in db1
4) Create users from db2 in db1
5) Place USERID & SECCODEID for users from db2 in a userinfo related table for each user (allows you to match USERID/SECCODEID values from db2 to new USERID values in db1 for the migrated users).
6) Check SITEKEYS table to make sure you won't have any conflicts in table ID values
7) Use SQL DTS to migrate data from db2 to db1, on the way in you'll have to translate the old USERID & SECCODEID values to the new ones (this is best done in a view instead of a row by row lookup). If there will not be any conflicts of table ID values (see step #6) then I just leave all ID values as they are in db2 and just dump them accross into db1. The only changed values are USERID and SECCODEID values.
That's the long and short of it. It sounds like a lot of work, but it really is not. DTS will do all the heavy lifting. I've gone this route many times and works a champ. However, I've not used the GroupCopy idea that was suggested. It might be an easier route, but seems to me that it might also leave some things unaccounted for.
Good luck. 
-Ryan |
|
|
|
Re: Merging Two SLX Databases into One...different version numbers
Posted: 08 Jun 06 1:51 PM
|
fiogf49gjkf0d This was a terrific tip, using GroupCopy. One of our sales people inadvertantly deleted an account recently, but we had a backup of the database. So, I was able to use GroupCopy to copy that account from the backup database into the live database. It seems to have worked perfectly, and it was very easy. I didn't want to restore the entire database as it was the day before, just the one record. And, this was the perfect solution for doing that.
Thanks! |
|
|
|
Re: Merging Two SLX Databases into One...different version numbers
Posted: 02 Dec 08 4:21 PM
|
Ryan, I am trying to following your instructions.. i need a little more guidance..
1) Which tables (SQL SSIS) we need to avoid importing to the destination database...Userinfo & usersecurity will be 2 of them..Is there any other table that I do not need to import????
2) How to I replace old userid & seccodeid with New userid & seccodeid in the view...
Thanks
Khevna |
|
|
|
Re: Merging Two SLX Databases into One...different version numbers
Posted: 22 Dec 08 9:04 AM
|
Why you aren't going to 6.2.6 or 7.22 or 7.5.1 is beyond me......6.2.3 is NOT the answer.
But yes upgrade each of the databases to the master version/schema in their own database and then merge them to the production final master database.
Your mileage will not vary.
The big key is non identical ID field values...... for all unique value ID's.....USERID, ADDRESSID, ACCOUNTID, SECCODEID, et al. This is a lot of tables and a lot of ID's and a lot of SQL. Plugins, Joindata, Lookups, Picklists, et al don't touch this.....use a bundle instead.
RedGate has a fantastic SQL database comparison and update/insert for data, indexes, and schema (fields and tables)...that's what I would use......
Step 1 is to get all databases 'on' the same schema.... apply SLX Service Packs as the first step in this....then a Schema bundle of field and table changes from the final DB (the MASTER) to the other DB's.
Next you will need to make ID values Unique.....SECCODEID, ACCESSID, ENTITYID, USERID, et al are problematical (CompletedUser in Activity for example is an UserID field value).....
Then start using SQL/SSIS/DTS or RedGate or Scribe or Innaport and move stuff around. SQL to EXCEL, mess around in EXCEL (make up ID Values, as long as they are unique they work just fine "USAZIP061011" for the POSTALCODE table works great for example)
Group Copy is Ok, sometimes misses important tables, takes a ton of memory, and is slow as snot.
|
|
|
|
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!
|
|
|
|
|
|
|
|