Input Parameters in an adp form

I am developing my first ADP client for a SQL db, after having used mdb's as
clients in numerous applications previously. I have found that
theoretically the Input Parameters property of a form in an adp and its
method of therefore enabling a form to be connected to a procedure that
requires parameters is really nifty. However in practice I am finding a
number of annoying issues with this, most particularly that the adp seems to
have intermittent issues adjusting the record source when the input
parameters are updated in code.

Am I wasting my time with this? Is this new feature full of bugs or is it
something I should be able to work thru?

re: Input Parameters in an adp form

On Mon, 20 Dec 2004 23:21:12 GMT, "Andrew Chanter"
<helpme@radsolutions.com.au> wrote:
[color=blue]
>I am developing my first ADP client for a SQL db, after having used mdb's as
>clients in numerous applications previously. I have found that
>theoretically the Input Parameters property of a form in an adp and its
>method of therefore enabling a form to be connected to a procedure that
>requires parameters is really nifty. However in practice I am finding a
>number of annoying issues with this, most particularly that the adp seems to
>have intermittent issues adjusting the record source when the input
>parameters are updated in code.
>
>Am I wasting my time with this? Is this new feature full of bugs or is it
>something I should be able to work thru?
>
>[/color]

ADPs are plain buggy and quirky, and a huge drain of time and money to try to
fight with. Besides, Microsoft seems not to be actively fixing or enhancing
them at all. I recommend you give up with the ADP thing.

re: Input Parameters in an adp form

Hi,

I am able to make some headway in developing an ADP project by using an
unbound form for input parameters which I keep open and invisible to
the user.

I pass the required parameter values into the controls on this form and
the forms with record scources that need input parameters in turn refer
to the controls on the input parameters form.

I have seen improvements in performance when the default values of the
text boxes on the input parameters form is set to Null (the default
value of the parameter in the stored procedure is also null) and by
populating the control after conveting the parameter value into the
relevant data type.

Is this method of passing parameters inadvisable?

Isaac

Steve Jorgensen wrote:[color=blue]
> On Mon, 20 Dec 2004 23:21:12 GMT, "Andrew Chanter"
> <helpme@radsolutions.com.au> wrote:
>[color=green]
> >I am developing my first ADP client for a SQL db, after having used[/color][/color]
mdb's as[color=blue][color=green]
> >clients in numerous applications previously. I have found that
> >theoretically the Input Parameters property of a form in an adp and[/color][/color]
its[color=blue][color=green]
> >method of therefore enabling a form to be connected to a procedure[/color][/color]
that[color=blue][color=green]
> >requires parameters is really nifty. However in practice I am[/color][/color]
finding a[color=blue][color=green]
> >number of annoying issues with this, most particularly that the adp[/color][/color]
seems to[color=blue][color=green]
> >have intermittent issues adjusting the record source when the input
> >parameters are updated in code.
> >
> >Am I wasting my time with this? Is this new feature full of bugs or[/color][/color]
is it[color=blue][color=green]
> >something I should be able to work thru?
> >
> >[/color]
>
> ADPs are plain buggy and quirky, and a huge drain of time and money[/color]
to try to[color=blue]
> fight with. Besides, Microsoft seems not to be actively fixing or[/color]
enhancing[color=blue]
> them at all. I recommend you give up with the ADP thing.[/color]