You've pretty much the same capabilities in an ADP as you did in an MDB. A
few things that come to mind off-the-bat that you should watch out for,
though:
- SQL Server 2000 is the most compatible with ADP; higher versions of SQL
Server won't let you make design changes from the ADP...I've never worked
with lower versions, so not sure about them.
- SQL Server doesn't support crosstab queries, and therefore neither does
ADP. You can "fake it" using a fairly cumbersome query...search the web or
the NG's for more info on that.
- When you do a quick sort (i.e., using the A-Z/Z-A buttons or menu
commands) in a table or view, if you're using Access' ability to look up
information (e.g., you've got a user id column, but you're having Access
look it up and display the user name instead), an ADP will still sort by the
underlying data, not the displayed data like an MDB would. I don't know if
they've fixed that in Access 2003 or not.
- For any programmatic data access, you'll have to use ADO when designing an
ADP, rather than DAO. On the one hand, it's a whole new ball game; on the
other hand, I found once I got used to the conceptual differences, it was
more powerful and generally easier to work with than DAO, without being THAT
different. (That said, if you're working in an MDB and have absolutely no
plans to move to a different platform at any point, stick with DAO...it's
WAY faster for MDBs!)
That's what comes to mind off-hand; there are probably dozens of other
things I'm not thinking of, though.
Rob
