Set Statement vs Function

2 Oct 2006 4:34 AM

Bryan

I have an mObj class to represent MS Access database tables in my
VB.net project. It handles all table schema stuff like adding columns,

setting properties of columns etc. For example, I have a property in
mObj called AllowBlanks. This is mapped to the 'Required' property of
a MS Access db column.

I have code in the 'Set' statement of the AllowBlanks property to
change the Access column's 'Required property' to whatever the user
submits as 'value' I am using ADOX to work with Access, example:

Private _BlanksAllowed As Boolean
Public Property AllowBlanks() As Boolean
Get
     Return _BlanksAllowed
End Get
Set(ByVal value As Boolean)
     Dim con As ADODB.Connection = DAL.GetADODBCon
     Dim db As New ADOX.Catalog

     con.Open()
     db.ActiveConnection = con

db.Tables(_ParentMobj.Name).Columns(_Name).Properties("Nullable").Value

= value
      con.Close()
     _AllowBlanks = false
End Set

Should I have this code here or in a separate function? If I keep it
in the Set statement, how will I know if the code failed or succeeded
when I set the value from a form later on? If it was in a function, I
could have it return false if the code failed.
Keeping the code in the Set statement makes my form code easier to read

mObj.AllowBlanks = True. But I don't understand how I can test if this

is succsesful in my code.
Having the code in a function would be more code in my forms:
SetAllowBlanks(mObj, True), but I could handle a failure if the
function returned false.

How have you all handled Set statements that could provoke an error?

2 Oct 2006 4:50 AM

Cor Ligthert [MVP]

Bryan,

You can throw an exception and set a catch on that.

I could not find a link on MSDN about exceptions although I have searched 15
minutes.
But it should be there, so maybe can you try it yourself.

I hope this gives an idea,

Cor

Show quoteHide quote

"Bryan" <bryanv***@gmail.com> schreef in bericht
news:1159763654.231595.160760@i3g2000cwc.googlegroups.com...
>I have an mObj class to represent MS Access database tables in my
> VB.net project. It handles all table schema stuff like adding columns,
>
> setting properties of columns etc. For example, I have a property in
> mObj called AllowBlanks. This is mapped to the 'Required' property of
> a MS Access db column.
>
> I have code in the 'Set' statement of the AllowBlanks property to
> change the Access column's 'Required property' to whatever the user
> submits as 'value' I am using ADOX to work with Access, example:
>
> Private _BlanksAllowed As Boolean
> Public Property AllowBlanks() As Boolean
> Get
>     Return _BlanksAllowed
> End Get
> Set(ByVal value As Boolean)
>     Dim con As ADODB.Connection = DAL.GetADODBCon
>     Dim db As New ADOX.Catalog
>
>     con.Open()
>     db.ActiveConnection = con
>
> db.Tables(_ParentMobj.Name).Columns(_Name).Properties("Nullable").Value
>
> = value
>      con.Close()
>     _AllowBlanks = false
> End Set
>
> Should I have this code here or in a separate function? If I keep it
> in the Set statement, how will I know if the code failed or succeeded
> when I set the value from a form later on? If it was in a function, I
> could have it return false if the code failed.
> Keeping the code in the Set statement makes my form code easier to read
>
> mObj.AllowBlanks = True. But I don't understand how I can test if this
>
> is succsesful in my code.
> Having the code in a function would be more code in my forms:
> SetAllowBlanks(mObj, True), but I could handle a failure if the
> function returned false.
>
> How have you all handled Set statements that could provoke an error?
>

2 Oct 2006 5:07 AM

Bryan

Thanks for the idea. So I guess I could create and throw a custom
exception object in my Set statement, then catch it at the form level.

2 Oct 2006 5:26 AM

Cor Ligthert [MVP]

yes

Show quoteHide quote

"Bryan" <bryanv***@gmail.com> schreef in bericht
news:1159765661.730120.277690@e3g2000cwe.googlegroups.com...
> Thanks for the idea. So I guess I could create and throw a custom
> exception object in my Set statement, then catch it at the form level.
>