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!
|
|
Migration to 7.0
Posted: 11 Apr 06 1:02 PM
|
fiogf49gjkf0d Does anyone have any information on the upcoming release of 7.0?
Specifically I would be interested in any information relating to migrating 6.1.2 to 7.0
Please tell me it wont be as painful as the migration from 5.2. I wasn’t here for that, but I heard the stories.
|
|
|
|
Re: Migration to 7.0
Posted: 12 Apr 06 2:33 AM
|
benadryl pregnancy nhs benadryl and pregnancy fiogf49gjkf0d 6.1 to 7.0 is a significant upgrade. Do not expect this to be a "flip of the switch". I am of course speaking from a customization standpoint. See other post in SalesLogix Scripting and VBScript entitled Managing Customizations.
Timmus |
|
|
|
Re: Migration to 7.0
Posted: 21 Aug 06 2:29 PM
|
fiogf49gjkf0d In preparation for the upgrade we went ahead and upgraded our server to Windows 2003 Server and SQL 2005. We'll then run in development mode for about 6 months before we cut over live.
The big change I'm excited about is that SalesLogix opened up the 'base' tables (like the Account table) for customization. This will allow me to get rid of some unnecessary 1-to-1 tables.
I'll have to start considering how to move my data around. I'll probably just use MSSQL DTSs rather than mess with Scribe again.
Marc |
|
|
|
Re: Migration to 7.0
Posted: 21 Aug 06 4:16 PM
|
fiogf49gjkf0d What is the reasoning behind customizing the base tables? I was sold on the idea of 1-1 extension tables long ago and I see little reason to switch back.
It was possible to create base table fields before but it took quite a bit of work. I don't see SLX allowing their fields to be dropped for integrity purposes so you're only gaining the benefit of adding new fields. Is there a clear indicator of mine vs. theirs? If not, fields are going to get mixed up quick.
I like the concept, I'm just not entirely sure I'm going to enjoy the implementation. |
|
|
|
Re: Migration to 7.0
Posted: 21 Aug 06 4:45 PM
|
fiogf49gjkf0d When you have to modify the "Products" part the ability to add to the core table (PRODUCT) is very useful and time saving. In fact I've been modifying core tables for several years and the way I do it is 100% complient w/what is in v7.0.
Additionally, to add just one or two fileds via teh 1:1 mechanism is a major time sink.
If you want to add your own base (new) entity to activities and Historry (as well as attachments) you MUST modify core tables.
--
rjl
SLXE7/SLXD7/SLXWE7 |
|
|
|
Re: Migration to 7.0
Posted: 22 Aug 06 4:37 AM
|
fiogf49gjkf0d Jeremy:
1-1 is a fine idea provided (and I know you will!) manage it properly. For example, when inserting records - do you want the 1:1 ? Or should you always create the 1:1. The issue here is if you have, say, 1000 contacts and 500 1:1 contact extension records and you do a Replace Data in the extension table it will only be possible to update the 500 existing extension records. This, of course, may not be what you wanted (or expected). You want to set context.col2 to "xyz". You then query your contacts (perhaps a few months down the line) and ask for each contact who is col2 = "xyz". Of course, you will only get 500 rows returned instead of the 1000 you were expecting. This gets very confusing. In our case (as a BP) we always create the extension record regardless.
The reverse (not creating the exension) is also sometimes desired - it just depends. If you are master of your destiny then that's fine - if you are a BP with a ton of systems to support and a support desk that has no idea what the developer did (or can't find out at that time) then query building and replace data are huge sources of issues for them as they can't figure out why it's only 500 of 1000 updating (obvious really).
There is nothing stopping you using 1:1 still - but for ease of updating and reducing the complexity of queries created the ability to update base tables is going to be great. The downside being I can quickly see people getting too carried away and hitting the row width ! |
|
|
|