-
I've got these 3 old VB 3.0 programs that our company is maintaining (but that's another story all together ;))
One of the apps refuses to compile, even though the code it is choking on, is exactly the same in all 3 apps. There is a variable declaration:
Global ds As Dynaset
Then in the code, a little something like this:
Code:
sql = "select count(*) from tempdb..mp_eac"
sql = sql & " where dat_ty_cd='S'"
Set ds = db.CreateDynaset(sql, 64)
sup_rec_count = ds(0)
When I go to run this app from the dev environment I get the following error, "Object is not an array". With the "ds" in the last line listed above highlighted.
I checked the code in the other programs and it is identical, any clues?
-
Are you saying that you compiled all three programs and only one of them does not work? The CreateDynaset is obsolete according to the MSDN. If you only tried to compile the one program and it is giving you the problem then it may be due to a newer version of DAO on the machine you are compiling from.
-
Yeah, I compiled all 3 of these apps on the same machine, with only one of them producing his error.
The thing is, I don't have time to rewrite these apps (all 3 created in VB 3.0 and are huge). Later this year, I'll be forcing the issue (again) of getting these apps ported to VB 6 as a major priority, until then it's all Band-Aids and chewing gum. ;)
-
OK, found a work around!
Well, I did some more digging on the internet and found an answer to this problem. It seems that there is a bug in the VB parser that prevents certain usages of a globally declared table var in a form.
To fix this, I added a sub routine to the form that tried to access the "ds" variable as such (named this way to force it to be the first subroutine in the form):
Code:
Sub AAAA_FixDS ()
ds.MoveFirst
End Sub
This subroutine never gets called, but tricks the parser to go ahead and know that "ds" is indeed a table var.
Whew! ;-)
