|
|
Posted by Steve Jorgensen on 10/14/05 17:37
The strategy I've arrived at is to have a table of working sets, and have the
table of selections include the working set key. When the user starts the
task, the program first makes a new working set record, and thus gets a new
unique ID for the set of selection records.
With this design, you can keep treating working sets as dynamic by deleting
them after use (and have a garbage collection process to empty out old ones
that failed to get deleted) or allow the user to name them, keep them around,
and refer to them again later.
On Fri, 14 Oct 2005 08:11:41 GMT, "Neil" <nospam@nospam.net> wrote:
>I am using SQL 7 with an MS Access 2000 MDB front end, using bound forms
>with ODBC linked tables. In one form, the user needs to be able to check a
>box to select one or more records. This is accomplished with a local table
>containing two fields: the primary key value of the SQL table and a boolean
>field used for the check box.
>
>Since the local table used to contain the boolean field is local to the MDB
>file, the result is a heterogeneous join in the underlying form query, which
>degrades performance. I would like to have the entire query be based on back
>end SQL data. However, each user needs to be able to make a unique set of
>selections, without other users' selections affecting theirs.
>
>An idea I have is to port the selections table to the back end with an
>additional field for machine name; create a view of the main table joined to
>the selections table; link the view to the front end; and base the form on
>the SQL: "Select * From MyView Where MachineName='MyMachine'".
>
>However, I wonder if there's a better approach. Any ideas would be
>appreciated.
>
>Thanks,
>
>Neil
>
Navigation:
[Reply to this message]
|