John W Colby
jwcolby at gmail.com
Thu Jan 31 15:25:43 CST 2013
Interesting. That means dynamically creating a named schema for each user needing this kind of thing and then linking to that schema table set, correct? John W. Colby Reality is what refuses to go away when you do not believe in it On 1/31/2013 3:15 PM, Stuart McLachlan wrote: > You asked about: > " plus (apparently) some data from those tables pulled down to > the FE and stored there over time as the user processes the data in those > local FE tables." > > Instead of pulling the data into FE tables, you copy the releavnt records from dbo.tblTable to > colby.tblTable. You then do whatever you want with that data. If you need to subsequently > update dbo.tblTable, you will need to do whatever you did previously with the data from the > FE tables. > > > On 31 Jan 2013 at 14:54, John W Colby wrote: > >> I had actually found and read this buut I didn't realize that it applied to the individual records >> inside of the tables. Suppose I have 10 loan officers, each has his own loans. Currently they are >> pulled down to thhe FE, worked on over a (longer than a day) time period, then the changes are >> pushed out to files used to feed back into the system. >> >> How does a schema allow each loan officer to have his own set of records on the server without >> append / update / delete conflicts with other loann officers records? >> >> John W. Colby >> >> Reality is what refuses to go away >> when you do not believe in it >> >> On 1/31/2013 2:45 PM, Stuart McLachlan wrote: >>> http://blog.sqlauthority.com/2009/09/07/sql-server-importance-of-database-schemas-in-sql-s >>> erver/ >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >> >