Command Object vs. Explicitly created RecordSet
Hello again,
Today I'm wondering about the Miracle of connecting to databases. I have read a number of conflicting articles in my ongoing exploration of ASP.
I have read that stored procedures are good!
I have read that implicitly created recordset objects are bad!
But if I don't need an updateable recordset which is better, using the command object with a couple of parameters to execute a stored Access query or explicitly creating a Recordset object with
cursorType=adOpenForwardOnly
lockType=adLockReadOnly
For that matter if i want to update data am I better off using SQL statements or recordset.update?
Also if I use the Command object I assume I loose the ability to specify things like cache size and page size, Yes?
Thanks
Paul
Peter J. Boettcher posted this at 13:23 — 26th October 2001.
They have: 812 posts
Joined: Feb 2000
It seems these days everyone has an opinion on what is better regarding ADO practices, sometimes it's just more of a personal preference, other times there really is a better way. Here's my preferences:
1) Stored Procedures are good (very good!), and should be used over in page queries all the time if possible. You gain an advantage in speed and power. I haven't used a query inside an ASP page for almost 2 years!
2) Some people don't like the command object, but when you're dealing with stored procedures it's a neccesity. There are times when it's more efficient to use the command object over the recordset object, like when you're not returning more than a row of data. I never use recordset to update or insert data (unless it's a large amount), I just pass the parameters to my command object which then passes them to my stored procedure.
3) Of course, there are times when you have to use recordsets, like when you're returning large amounts of data, or when you want to setup paging.
4) If you're using a command object and a recordset object, then you can still specifit cache and page sizes.
5) Try to use the OLEDB provider for all your database work, it's faster than using ODBC.
PJ | Are we there yet?
pjboettcher.com
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.