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:
On Mon, 20 Dec 2004 23:21:12 GMT, "Andrew Chanter"
<he****@radsolutions.com.au> wrote:
I am developing my first ADP client for a SQL db, after having used
mdb's asclients in numerous applications previously. I have found that
theoretically the Input Parameters property of a form in an adp and
itsmethod of therefore enabling a form to be connected to a procedure
thatrequires parameters is really nifty. However in practice I am
finding anumber of annoying issues with this, most particularly that the adp
seems tohave 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 itsomething I should be able to work thru?
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.