Home | Forums | Contact | Search | Syndication  
 
 [login] [create account]   Friday, July 4, 2025 
 
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!
 Web Forums - SalesLogix Web Platform & Application Architect
Forum to discuss the use of the SalesLogix Web Platform, Client and Customer Portals, and the Application Architect (For version 7.2 and higher only). View the code of conduct for posting guidelines.
Forums RSS Feed


 Back to Forum List | Back to SalesLogix Web Platform & Application Architect | New ThreadView:  Search:  
 Author  Thread: Conversion to 7.5 Web-Combine C_extension tables with core?
Jeff Parker
Posts: 32
 
Conversion to 7.5 Web-Combine C_extension tables with core?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 10 Sep 09 11:06 AM
We are soon upgrading to 7.5 from 7.2 AND converting from Client Server to Web. In previous versions core tables were locked down and therefore, we have numerous 1-to-1 extension tables off of the core tables such as Account, Contact, Opportunity. Now that fields can be added to core SLX tables are people combining these tables? Are there performance concerns or guidelines to consider when contemplating merging these tables into one?

Jeff
[Reply][Quote]
Raul A. Chavez
Posts: 1300
Top 10 forum poster: 1300 posts
 
Re: Conversion to 7.5 Web-Combine C_extension tables with core?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 10 Sep 09 12:01 PM
We went through this conversion and let me tell you, there are some gotchas that you need to consider:

- If your users heavy utilize Group or Mail Merge, you would have to manually revisit each one of them.
I was doing this for about 4,000 users, and they had plenty of groups. I somewhat automated the conversion by programatically altering the Group and the Mail Merge definition, but I still got a big margin of error, probably close to 10%

- The DBAs did bring up the point that even though SQL allows for bigger row definitions. There are some technical issues on how SQL handles large rows which breaks them appart and may make query them a bit slower.
In our case we were able to prove that our actual row size was quite small (thanks to varchar fields), so we were allowed to proceed.
Obviously, the advantage is that the data, in this case is faster to read and you require less indexes, Joins, etc to read the data.

Guidelines ?
Don't rename the fields
Don't change the schema
Someone working with me modified the schema of a field (and some field names) but that is what lead to my 10% margin of error on the Automated "Migration" of groups and Mail Merge Templates.

[Reply][Quote]
 Page 1 of 1 
  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!
 

 
 slxdeveloper.com is brought to you courtesy of Ryan Farley & Customer FX Corporation.
 This site, and all contents herein, are Copyright © 2025 Customer FX Corporation. The information and opinions expressed here are not endorsed by Sage Software.

code of conduct | Subscribe to the slxdeveloper.com Latest Article RSS feed
   
 
page cache (param): 7/4/2025 3:10:48 PM