Utility Belt has this heavily overloaded sub/method called DBPopulate and spDBPopulate. They are the easiest thing to use and allow you to use a line of code where you needed 10 or 20 or 30 lines of your code before. And your 1 line often triggers the running of dozens or hundreds of lines of code that is better code than you would have written.
Documenting DBPopulate or spDBPopulate is tricky. Using it is easy.
- the 1st. parameter is a connection string, but it is not just a typical connection string you use in an app although that will work. It can be the name of a appsettings key in web.config with a connection string, or a filename (mappath is optional) of an access file.
- the 2nd parameter is a sql string or Stored procedure name
- the 3rd parameter could be
So the clever thing is DBpopulate replaces the many lines of code to fill a webcontrol, the ExecuteScalar command and setup/teardown code, the code to populate a Datareader, the code to populate a datatable, and the code to transfer database data into a one dimension or multidimensional array, and as a bonus can do all those things if a Sproc is involved even a Sproc with parameters. And Try/Catch/Finally error trapping and resource disposal is built-in and pretty and custom error messages are built in too. And logging and profiling when you dig deep. And some caching approaches that eliminates many lines of caching code instead replacing it with 1 or 2 line directives that implement hundreds of lines of caching code.
The 4th parameter onward is where it gets interesting.
- the 4th. parameter can be a hashtable in some rare cases. In that case the name of each hashtable element and corresponding value should correspond to a stored procedure parameter. (not recommmended to use a hashtable most of the time, but pre 1.0 UB code may use a hashtable)
-or most of the time -
- the 4th. parameter can be a the name of a SProc parameter and the 5th a value for that parameter
- the 5th. parameter can be a the name of a SProc parameter and the 6th a value for that parameter
- and so on
- Samples of calling Stored procedures are at
DBPopulate and spDBPopulate may only be 1 line of code but what they do under the cover is rich and varied and keeps you from having to write a lot of code that you may not write the best way when in a hurry; the 3-12 line way most people prep and teardown executescalar, fill controls, and populate arrays and readers and datatables is often not the "best practice".
DBPopulate and spDBPopulate guarantee the code your app follows all best practices and has robust error trapping and disposal and logging.