Oh, boy, this is a fun one.

I have logic (that I didn't write) that looks at the seccodeid to determine how to assign an opportunity to a region. It's hard coded with a "Select Case" statement, with each seccodeid being a "case". Of course, now I need to do development on our instance and not the customers. The problem will arise that when I create the teams in production, the seccodeid may be different than what I generated in development for the new teams, breaking any new "case" statements I have.

Is there any way to bundle the creation of a team on the server an apply it to dev? I know I can have it insert a record and I can grab the seccode table records I need and NOT generate a new ID on install, but if I do that, what other records will I need to get besides the seccode table? Looking in JOINDATA I see a join to USERSECURITY. Is there any other table I would need to include?

Another idea I had was to create the teams in prod and then restore a backup to dev so the IDs would match.

A third idea: not hard code the case statement.

Anyone have any ideas on this?

Thanks in advance,

Jeff

Thanks, Mike. I thought there would be more tables to be populated. I contemplated running SLX Profiler to find out, but didn't.

As for not hard-coding, that's the ideal. I did find that their seccodeids for teams in prod are the same as our dev so if I create them teams in the same order, I'd probably be OK. I do want to look into using the team name but I'm not sure which would be faster now, which is apparently what is most important (and that is not my determination). It's definitely a code tax if I continue the hard coding.

Jeff

Just went through this.....create on Production.....backup production, restore on Dev SQL server....move your development to the 'dev' production.....think of it as a Test of your upgrade.....resume development in the 'dev' production database....including your CASE sql statements....

We actually had to do this for 250 USER's and their CreateUser, ModifyUser, CompletedUser values......a Tad more involved than Teams.....but a similar principle.

Thanks to everyone for the info.

It took a little longer to do, but I convinced the appropriate people it was best to go the non-hard coded route even though it took some extra work. I created a table with a FK to seccode. I called the foreign key field on my table seccode_id to avoid the provider applying security. On that table I have the region code and a flag if it's a "real" region (there are some teams that aren't actually regions). I wrote a SQL script to populate my table (no remotes) and now everything can go through the database instead of being hard coded. I paid someone elses code tax...

The only thing I didn't do was create a management screen, but the regions don't change frequently enough to make it worthwhile...

Thanks again!

Jeff