OpenRecordset bollocks
-
Yo all, have entered a stupid problem which I'm not sure is a bug in VB. I have this code:
Dim Record as Recordset, DB as Database Set DB = OpenDatabase("c:\db.mdb") Set Record = DB.OpenRecordset("BASE")Yet this remarkably simple code falls over when setting the recordset, because there is a "data type mismatch" (groan), when in fact there is no data type mismatch. OpenRecordset returns, guess what, a recordset, so wtf????? To add insult to my injuries, if I declare Record as a Variant instead, the line proceeds and guess what, Record gets cast to a, wait for it, Recordset object (ie. I can access the variant as I would a recordset and in debug the fields are identical), and all the data is intact and correct. Also, interestingly (though wankily) if I cast the Recordset object to a variant using CVar and then call OpenRecordset, I get no errors and indeed no recordset object, its just set to 'Nothing'. Is this just another episode of why VB is so shit? Can someone explain to me how a function returning a Recordset object can have a data type mismatch when trying to assign to a Recordset object??? Honestly, this is basic programming logic which this stupid, shitting language cannot grasp. I await someone to prove me wrong. -
Yo all, have entered a stupid problem which I'm not sure is a bug in VB. I have this code:
Dim Record as Recordset, DB as Database Set DB = OpenDatabase("c:\db.mdb") Set Record = DB.OpenRecordset("BASE")Yet this remarkably simple code falls over when setting the recordset, because there is a "data type mismatch" (groan), when in fact there is no data type mismatch. OpenRecordset returns, guess what, a recordset, so wtf????? To add insult to my injuries, if I declare Record as a Variant instead, the line proceeds and guess what, Record gets cast to a, wait for it, Recordset object (ie. I can access the variant as I would a recordset and in debug the fields are identical), and all the data is intact and correct. Also, interestingly (though wankily) if I cast the Recordset object to a variant using CVar and then call OpenRecordset, I get no errors and indeed no recordset object, its just set to 'Nothing'. Is this just another episode of why VB is so shit? Can someone explain to me how a function returning a Recordset object can have a data type mismatch when trying to assign to a Recordset object??? Honestly, this is basic programming logic which this stupid, shitting language cannot grasp. I await someone to prove me wrong.OK guys, found the answer elsewhere on the web, and guess what, its shit. Basically VB defines two recordset objects, both called 'Recordset', for ADODB and DAO, which is fair enough. However, fatally, VB CANNOT differeniate between the two, so whenever you specify
Dim Record as Recordsetit always assumes you are using the ADODB recordset object, hence the data type mismatch because OpenRecordset returns a DAO recordset, duh. This is exactly why VB is shit. C++ adopts a technique of namespaces, if there is ambiguity in the type the compiler will throw an error saying 'use of ambiguous types', nice, addresses you to the problem. VB just kicks up some bullshit AT RUN-TIME, which is horrible, horrible, horrible, because no end of bugs could manifest themselves. You even have to specify Option Explicit to force the compiler to point out basic compiler errors such as undeclared identifiers. This is wank. Anyway, the solution is declare the recordset as part of the DAO 'namespace' like soDim Record as DAO.Recordset. VB should be burned on a cross and sent to hell for its sins -
OK guys, found the answer elsewhere on the web, and guess what, its shit. Basically VB defines two recordset objects, both called 'Recordset', for ADODB and DAO, which is fair enough. However, fatally, VB CANNOT differeniate between the two, so whenever you specify
Dim Record as Recordsetit always assumes you are using the ADODB recordset object, hence the data type mismatch because OpenRecordset returns a DAO recordset, duh. This is exactly why VB is shit. C++ adopts a technique of namespaces, if there is ambiguity in the type the compiler will throw an error saying 'use of ambiguous types', nice, addresses you to the problem. VB just kicks up some bullshit AT RUN-TIME, which is horrible, horrible, horrible, because no end of bugs could manifest themselves. You even have to specify Option Explicit to force the compiler to point out basic compiler errors such as undeclared identifiers. This is wank. Anyway, the solution is declare the recordset as part of the DAO 'namespace' like soDim Record as DAO.Recordset. VB should be burned on a cross and sent to hell for its sinsYeah, I know exactly what you mean. It just totally disgusts me how flimsy the compiler is, and annoying when have a line
myvar =and then press enter and it comes up with a box saying you did something wrong, when really you were just gonna cut and paste some code. I only use VB when absolutely necessary, like when I have to knock up some bullshit app in a day or so. Its strange mind, cos this guy at work, Mark, he loves VB, personally I think he must be a bit sadistical to love VB. Lots of Love Simonxxxxx.