Generally speaking, utilty methods are candidates for being made static. For
example, if you look at the DAAB v2 "SqlHelper" class, everything is static.
-- Peter
Recursion: see Recursion
site:  http://www.eggheadcafe.com
unBlog:  http://petesbloggerama.blogspot.com
BlogMetaFinder:    http://www.blogmetafinder.com

RichB,

You do not need to instantiate a class nor use an abstract class for static
methods. No matter what class a static method is in you can reference/call it
via <classname>.<methodname>(<any paramaters>). Hope this helps.

One reason I got the non-static route is because I have 2 or 3 ways I might
use an alternate connection string.

   public abstract class DataLayerBase
   {

       private string _instanceName = string.Empty;

       public DataLayerBase()
       {        }

       public DataLayerBase(string instanceName)
       {
           this._instanceName = instanceName;
       }

       protected Database GetDatabase()
       {
           Database returnDb = null;
           if (this._instanceName.Length > 0)
           {
               returnDb =
DatabaseFactory.CreateDatabase(this._instanceName);
           }
           else
           {
               returnDb = DatabaseFactory.CreateDatabase();
           }
          return returnDb;
       }
   }

   public class ZebraData : DataLayerBase // all DAL objects inherit from
DataLayerBase
   {
       //Procedures
       private readonly string PROC_ZEBRA_GET_ALL =
"[dbo].[uspZebraGetAll]";

       public ZebraData() : base()
       {
       }

       public ZebraData(string instanceName) : base(instanceName)
       {
               //use a named connection string
       }

       public IDataReader ZebraGetAll()
       {
           IDataReader idr = null;
           try
           {
               Database db = base.GetDatabase();
               DbCommand dbc =
db.GetStoredProcCommand(this.PROC_ZEBRA_GET_ALL);
               idr = db.ExecuteReader (dbc);
               return idr;
           }
           finally
           {
           }

       }
   }

So I can use the "defaultDatabase", when I call the empty constructor, or
use one of the named connection strings when calling the constuctor with one
string argument.

Obviously, you can do this via overloaded static methods as well.  I just
chose the instantiated route.
I actually have a third overload, (not shown), because I created this small
"DatabaseCreationArgs", which allow you to set up parameters like
"ExcelFileName", and give you a well formed Excel connection string.

Aka, I have a third constructor...(not seen).

Obviously Im using the EnterpriseLibrary.Data to do my dataaccess as well.

Anyway, just giving you a food for thought about this.

I often debate which to do, but I went with this one.  Aka, I think about
just using static methods, and the overloads, but I also want clear intent
for maintenance reasons

One major advantage of not using static methods is that it allows you to
replace/stub out the functionality for unit testing without a database.
Or you can use different DAL implementations for Sql Server, Oracle, XML etc.