Posted by Neil on 11/17/55 11:29

Hi, Steve. Elsewhere in this thread I said to "ignore my other post," so I'm
thinking that my post here got ignored, when I actually meant the other one.
Thus, I'm reposting it below, in case that happened. Thanks!

Neil

Original post:

That sounds fine, and is similar to what I mentioned (working set key would
be machine name). When you used these, were they linked to an MDB or were
they just back end processes? I need to be able to use this in a bound form
approach, where the selection check box on the form is bound to the
selection table. Thus, the recordsource for the form needs to just return
the records pertaining to a particular working set key. How did you
accomplish that?

Thanks,

Neil

"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:acgvk19jgev07llcb80rlggdqcu7emqj1i@4ax.com...
> 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
>>
>

[Back to original message]