11/25/2024 8:22:56 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 upgrading SalesLogix from version to version. View the code of conduct for posting guidelines.
|
|
|
|
v7 Upgrade: Index cleanup
Posted: 18 Apr 07 11:34 AM
|
v7 includes the Sample MSSQL Indexes script, which I was going to use to rebuild indexes. The problem with that is all of the indexes/primary key constraints are named completely different than even the blank 6.2 database.
Here are my concerns:
1) Is there a problem with the deletion of the primary keys and indexes using alter table statements? The data is still there so all I'm changing is pointers to that data and more specifically how that data is sliced in SQL (to oversimplify a complex process).
2) This is to combat Task 19 in the upgrade document. When the upgrade bundle is ran it fails to convert fields due to index and constraints. I figured if I scripted the deletion, ran the bundle, then scripted their creation the remotes would get all of the changes during their sync.
I've updated my development database which is a fresh 6.2 blank. I had no problem removing constraints or indexes so I'm not too concerned but I do need to know what impact it'll have on production. As long as the statements are scripted and ran through Execute SQL in Administrator I shouldn't really have a problem. The production database started from a 3.16 database (at least, possibly older) so it'll most likely need quite a scrub. |
|
|
|
Re: v7 Upgrade: Index cleanup
Posted: 30 Apr 07 10:40 AM
|
fiogf49gjkf0d I guess I really didn't word this correctly or in the form of questions but here's my answers:
1) The OLE DB Provider doesn't process all alter table statements (specifically alter table drop constraint).
2) Drop index table.index would return -1 instead of 1 row
3) Needless to say, it's impossible to script an index cleanup for use in Execute SQL in Administrator
So, long story short the only way to redo/cleanup indexes is to hit EACH DATABASE using SQL statements. If done on the host, new remotes will be fine but existing remotes will have to be touched individually. Luckily in my case this happens to be only 4 databases.
I haven't quite figured out the best way to handle Task 19 though. Most likely it'll involve dropping the indexes for those tables specifically, installing the bundle, dropping ALL indexes, then rebuilding them all correctly. None of the index changes will sync out so no harm, no foul. |
|
|
|
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!
|
|
|
|
|
|
|
|