Paul,
Thanks for the input. Actually I had the enum in there, but I pulled it because I think I'm going to do an enaum for DB type, SQL, Access, MySql, ect, then determine internally which provider to use. I will also dynamically configure the connection string.
This way, all I have to do is set DBType, ServerName, DBName, UserName and Password and the class will do the rest.
What do you think?
>>
>>By this is pretty good for a first attempt. What do you think?
>
>Mind some constructive criticism? (I don't mean any of this to come across snarky)
>These are just mostly "standards" people use, so it really won't effect how your code works in any way.
>
>I'd suggest you use an enumeration instead of an integer, it makes the code a bit easier to read.
>
>ex.
>
>
>public enum ConnectionType
>{
> Sql,
> OleDB,
> ODBC
>}
>
>
>Then your switch looks like:
>
>
>switch (iConnectionType)
>{
> // Sql Data Provider
> case ConnectionType.Sql:
>...
>}
>
>
>Members of a class are also normally either private or protected. If you need to expose them, create a property (a member with a get/set).
>
>ex..
>
>
>private string sConnString = "";
>public string ConnString
>{
> get { return this.sConnString; }
> set { this.sConnString = value; }
>}
>
>
>Also, I think you'll find most .NET devs don't use type prefixes like we do in VFP. Local vars/parameters are camel case (lowerCase). Members are either name m_memberName or _memberName. Properties are usually ProperCase.
Everything makes sense in someone's mind
public class SystemCrasher :ICrashable
In addition, an integer field is not for irrational people