Home | Forums | Contact | Search | Syndication  
 
 [login] [create account]   Monday, November 25, 2024 
 
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!
 Administration Forums - Database Administration
Forum to discuss SQL Server or Oracle database administration related to SalesLogix databases. View the code of conduct for posting guidelines.
Forums RSS Feed


 Back to Forum List | Back to Database Administration | New ThreadView:  Search:  
 Author  Thread: Import with Scribe into Test; Copy via SQL into Production?
Zaurusman
Posts: 44
 
Import with Scribe into Test; Copy via SQL into Production?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 29 Oct 07 10:28 AM
Hi,

I'm in the process of "reloading" SalesLogix, in a development environment. I've started with third party accounts and contacts data, using Scribe to import them into a mostly empty SLX SQL Server database. I will next be moving this data to production when appropriate, copying them again to an mostly empty database (with account and contact related tables that are completely empty). With Scribe having already generated the IDs' values, is there any reason not to save a lot of time simply copying these to the clean database via SQL? Or there a "next" ACCOUNTID, CONTACTID, ADDRESSID, etc, stored somewhere in the database?

TIA!
[Reply][Quote]
Frank Chaffin
Posts: 475
 
Re: Import with Scribe into Test; Copy via SQL into Production?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 29 Oct 07 11:35 AM
The next ID value (sequence#) is stored in the database as the table level. The value generated is based on the SiteCode of the station doing the insert and the sequence#. If you understand how this works (which is sounds like you are not) and are sure there will never be a collision, you can import the records as is, otherwize, I think you should let Scribe generate new IDs
[Reply][Quote]
John Gundrum
Posts: 632
Top 10 forum poster: 632 posts
 
Re: Import with Scribe into Test; Copy via SQL into Production?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 29 Oct 07 2:08 PM
Have to agree with Frank. Copying the data over is risking duplicate IDs. You are much better off letting Scribe do the business of importing the data.

Is there a reason that necessitates bringing the data from the development database into production?

John G.
[Reply][Quote]
Walter Shpuntoff
Posts: 167
 
Re: Import with Scribe into Test; Copy via SQL into Production?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 30 Oct 07 4:51 AM
As long as the sitecodes are different, you should be fine.

ws
[Reply][Quote]
Zaurusman
Posts: 44
 
Re: Import with Scribe into Test; Copy via SQL into Production?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 30 Oct 07 9:46 AM
Quote:
Is there a reason that necessitates bringing the data from the development database into production?


Well, going through SQL would avoid the week delay it takes Scribe to import all the contacts and accounts (and address records) we're talking about here. Might be faster in production since it's not a virtual machine, but that's a long implementation either way. I'm trying to avoid that going into production if I can get that piece of it lined up in test, and only use Scribe to pull over current SalesLogix data we're keeping going forward.

Quote:
As long as the sitecodes are different, you should be fine.


Which site codes are we talking about? I know each user has one and that those are the same across all of our environments; I copy over the database and do not truncate any user tables.

Thanks guys.
[Reply][Quote]
Walter Shpuntoff
Posts: 167
 
Re: Import with Scribe into Test; Copy via SQL into Production?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 31 Oct 07 5:56 AM
SYSTEMINFO has a field SITECODE that is used as the basis for the record key.
Each database that sync's together is supposed to have a unique 4 letter combination here.
(Note: Database, not user level)
SITEKEYS has the current "high water" mark for the key value.

Essentially - a SLX record key is
1. a one character table designator (C=Contact, A=Account, H=History, Q=Other, etc)
2. The site code for the database it was created in
3. The appropriate SITEKEY+1 (base 36)

SITEOPTIONS has a list of the SITECODES that have been used by the database (so it doesn't accidently re-use the code when you cut a new database.)

To create a database with a new sitecode:
1. Copy a DB and change the value in Systeminfo to whatever 4 letter code you want. (I am assuming this is your DEV db)
2. If you have remotes and are worried about the (very small) chance of the sitecode being regenerated for a remote, make an entry in SITECODES in the production database that matches what you used in your dev database.
Something like Insert into sitecodes(sitecode, hostserver) values('XXXX', 'NOSYNCSERVER')
(assuming that the sitecode is XXXX)

Sitekeys will take care of itself.
If the database is already set up for sync.... you have a bit more work to do. I am assuming that you are not synching this yet.

Make sense?

ws
[Reply][Quote]
Zaurusman
Posts: 44
 
Re: Import with Scribe into Test; Copy via SQL into Production?Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 31 Oct 07 10:31 AM
Makes perfect sense, Walter. Thanks for your help!
[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 © 2024 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): 11/25/2024 4:19:11 PM