1

Please see the DDL below:

CREATE TABLE TestDate (bookingdate datetime)
INSERT INTO TestDate VALUES ('2013-10-04')

Please see the ADODB recordset below:

rs.open "SELECT bookingdate FROM TestDate"
If rs("bookingdate") > dateadd("yyyy", -6, Now)
  msgbox("test")
end if

What is the difference between specifying rs("bookingdate") and rs("bookingdate").value. I have read some questions on here where answerers say always use .value, but it is not explained why. I had a look on MSDN but could not find an answer.

GSerg
  • 76,472
  • 17
  • 159
  • 346
w0051977
  • 15,099
  • 32
  • 152
  • 329
  • The "why" is the same risk factor involved in any use of a default property. People will blithely ignore this and get away with it 99 times out of 100 and then that 100th time get bitten HARD by a very hard to diagnose bug. – Bob77 Oct 05 '13 at 22:24

1 Answers1

2

Value is the default property of the Field object, so in VB6 there is no difference between rs("bookingdate") and rs("bookingdate").value when used without Set.

I personally prefer not using default properties that don't take parameters. It makes the code less confusing IMO.

In VB.NET the default property must have a parameter, so this situation does not occur.
Note Recordset has such default property with parameter, and you are using it to return the Field object: rs("bookingdate") is actually rs.Item("bookingdate"). Using those, IMO, makes no harm.

Community
  • 1
  • 1
GSerg
  • 76,472
  • 17
  • 159
  • 346
  • SET involves manipulating the reference according to your link. Is that correct? – w0051977 Oct 05 '13 at 17:36
  • @w0051977 Yes, it involves manipulating the reference. E.g. you could declare a variable `f` of type `Field` and `Set f = rs("bookingdate")`. – GSerg Oct 05 '13 at 18:14
  • Not true. There are many cases where `Set` isn't a factor, such as any time you pass the expression as an argument to some procedure. – Bob77 Oct 05 '13 at 22:23
  • @Bob77 While passing parameters is a different matter that has little to do with assigning variables, it also may or may not use default properties (which also adds confusion). If you take expression `rs("bookingdate")` and pass it to a procedure that accepts a `Field`, `Object` or `Variant` parameter, the `Field` object will be passed. If you pass same expression to a procedure that accepts e.g. a `String` parameter, the compiler will call `rs("bookingdate").Value` and pass that. – GSerg Oct 06 '13 at 08:05
  • It seems like everyone wants to contrive examples to prove that lazy reliance on default properties is a healthy thing. It *isn't* and has never been a recommended practice. It makes it harder for anyone (including the compiler) to know what's intended. However... you always have the option to do so, it just isn't considered good practice. – Bob77 Oct 06 '13 at 17:07
  • @Bob77 Who is doing that? [I'm not](http://stackoverflow.com/a/19200523/11683). The people the OP met [aren't doing it](http://stackoverflow.com/q/19200428/11683) either. – GSerg Oct 06 '13 at 17:47