For 13+ years (including today), SalesLogix has used a method of adding/dropping fields (via the db manager) that has involved several steps:
A – Renames theoriginal table to xtempx_TableName
B – Create the newtarget table but it has no data
C – Adds the newfield to the new target table
D – Copies the databack from the xtempx_ table to the new table
E – Deletes thextempx_ table
This method was employed for several reasons:
A - the "BDE" (Borland Database Engine) <- No longer exists as of SalesLogix v6.0
B - Early SQL server did not support "Alter Table, Alter Column <- It does now as (Oracle does too)
C - The "SalesLogix Provider did not support the "Alter" command <- Does as of SalesLogix v6.2.6 (maybe slightly earlier.. but it does not matter)
All the reasons to NOT do it the short and sweet way no longer exist.
Doing it the "long" way has caused many problems over the years and is a lurking "time bomb".
We just tripped into this on a (large) customer site where there are TaskCentre (controlled) SQL Triggers that are used for initiating Tasks/WorkFlows. As soon as a field is added/dropped (via the SalesLogix DB manager) , the trigger is "left behind" on the xtempx_ table.
This not only will happen w/TaskCentre managed SQL Triggers but also w/ANY triggers one may have setup against their SalesLogix database.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We want to hear your cool ideas for enhancing Saleslogix products and services. So add your own ideas or kudo (vote) on the ideas of others here! Watch the most valuable bubble to the top!
I have an idea! How do I get started?
One