Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
pithhelmet
Posting Yak Master
183 Posts |
 Posted - 2006-11-27 : 14:35:28
|
| Hi everyone -is there a qnd that will create a series of work tablesthat will include the related tables?Here are my thoughts....User connects to the web service, the web service createsan empty set of new work tables, (if there is existing data i.e. update scenerio) then the data is brought over to work tables.all users work against the web service and its datasources that point to the work tables,when the user presses save, the data is written to the master databases as either an update or insert methods.I know - it sounds like a lot of extra operations to work like this,but the spatial data and the tabular data MUST be in synch at the time of the user pressing save, and i think the user workingagainst thier own sandbox of data will eliminate cross pollenation of data.The web service will hold the locking of the records in the production system in its own table via a GUID that is assigned to the client - this will eliminate the problem of multiple people using the same datasets on the server as they are checked before allowing the data to be worked against.I was also thinking of using a mirror set of all the tables and have an additional field added to them (the GUID) and populate this field when the records are checked out, and removed when they are checked in....thoughs or suggestions would be appreciated.thankstony |
|
|
snSQL
Master Smack Fu Yak Hacker
1837 Posts |
Posted - 2006-11-27 : 15:03:28
|
| Creating a new set of work tables for each session is overkill, just create a set of work tables using the script from your existing tables and add the session id (your GUID) column to each work table. Then do all the data work in that one set of work tables, every user's data is kept separate by the session id in the data, it doesn't have to be in separate tables for each user just to keep it unique to the user. |
 |
|
|
pithhelmet
Posting Yak Master
183 Posts |
Posted - 2006-11-27 : 16:15:45
|
| Thanks for the reply -I was leaning to that solution myself -thanks for the replytake caretony |
|
|
|
|
|
|
Duplicate related tables