|
|
Posted by Neil on 10/19/05 19:15
Hi, Larry! The problem is that the customer really likes the way it's set
up. They have a bound check box control in the form, which they use in form
view or datasheet view, and it's an integral part of how they work with
records. To get them to give up the check box would be hard. Thus, somehow
the field needs to appear in the form with its current selection status.
A new wrinkle, though: I just found out that the selections do not need to
persist between instances of the form. (Previously I thought that that's how
they were using them; but I found out that they actually do all their
selecting and working with selections in a single session.) So that opens up
other possibilities.
Neil
"Larry Linson" <bouncer@localhost.not> wrote in message
news:ePE08HE1FHA.1252@TK2MSFTNGP09.phx.gbl...
> "Neil" <nospam@nospam.net> wrote
>
> > The machine name changing isn't an issue,
> > since these selections are temporary -- maybe
> > a few hours or overnight at the most. They're not
> > permanent entities.
>
> How about constructing the T-SQL update Query in code and using it as a
> Passthrough Query, or creating a Stored Procedure to which you pass
> parameters, or, indeed, just creating a Jet query based on information
> from the local table, but that does not Join to the local table -- one of
> these approaches might avoid the delays, which are, as you pointed out,
> due to using a heterogeneous join.
>
Navigation:
[Reply to this message]
|