What good are forms in ADP?

[Allen_N]

I am routinely surprised and disappointed at the amount of functionality one
has to give up when upsizing from an MDB to an ADP (Access 2003). Now I find
that setting the 'Decimal Places' field to 2 (on the Format tab of the
Properties window) has no effect on the number of decimal places displayed in
a column (in Datasheet view) -- I still get 10 instead of 2. What is this
setting for?

In MDBs I often used forms in Datasheet view instead of opening the query
itself, because of the filtering, ordering, and formatting possibilities.
Conversely, there don't seem to be many reasons to use forms in an ADP.

Is there a list somewhere of all the deficiencies of ADP (with respect to
forms & reports as implemented in MDB), along with possible work-arounds?

 

[Allen_N]

Thanks Baz,

Not sure what this is doing in the modulesdaovba newsgroup, but anyway:

Sorry; I assumed I'd have to resort to programming to emulate things that
MDP forms provide via their Properties and Events.

I just realised I can use the WhereCondition parameter with the OpenForm
method to do filtering, so that's 1 item off my list.

The Decimal Places property works as advertised if you use it in conjunction
with the Format property. If you don't specify a Format, then no, Decimal
Places has no effect.

I'll try that.

Your post suggests that you are just beginning with ADP's. If so, I would
think again if I were you. Microsoft's enthusiasm for ADP's lasted no
longer than Access 2000, and has been no better than lukewarm since then. ...

So what's a good alternative, if you want a nice GUI for building forms &
reports? (MS Enterprise Manager is intimidating, and I'm not even sure it
will do what Access does in this regard.)

 

[Baz]

Thanks Baz,


Sorry; I assumed I'd have to resort to programming to emulate things that
MDP forms provide via their Properties and Events.

Although DAO is irrelevant in ADP's, you are pretty much compelled to use
ADO.

I just realised I can use the WhereCondition parameter with the OpenForm
method to do filtering, so that's 1 item off my list.

You also have the same filter properties as you have in MDB, plus in
addition the ServerFilter. On the subject of server filters, you need to
watch out for the DataEntry property of forms in ADP: on the face of it, it
seems to work the same way as in MDB, but in reality it's broken. If you
open a form with DataEntry set to true, the entire record source of the form
is queried, even though none of the records is displayed in the form (easily
proved using the SQL Profiler). This, in my opinion, renders the DataEntry
property useless. I get round this by using the ServerFilter property: in
the form's design, I set it to something that will never return any records
i.e. I specify in the server filter that the primary key should be null.
Then, if I want a form that is not in my "pseudo data entry" mode, after
opening it I set it's ServerFilter to something more appropriate.

So what's a good alternative, if you want a nice GUI for building forms &
reports? (MS Enterprise Manager is intimidating, and I'm not even sure it
will do what Access does in this regard.)

No, the SQL Server Enterprise Manager is certainly not a tool for building
applications.

Microsoft has nothing against you using Access as a front-end to a SQL
Server database, it's just that they would prefer you to use linked tables
from the new accdb thingy rather than ADP. Much as one dislikes being
dictated to by Microsoft, to do otherwise risks having the rug pulled from
under you at some time in the future (just ask millions of VB6 users...).

Personally, I've become quite partial to ADP's over the last few years, but
they can be buggy and frustrating, so I'm quite looking forward to seeing
what these accdb creations can do.