Article Discussion: Developing a VBScript Class for an Extremely Lightweight Recordse

If you have any questions or comments about this article please post them here.

This forum post relates to this article

fantastic stuff!
having reviewed the code, i have 2 questions.
i e-mailed Tom and have posted his replies after each question:

QUESTION:
1) is there any specific reason why you chose to pass a recordset object to the Load function rather than create (and destroy) the recordset inside of the function itself?
i was thinking of this:
- passing the connection string and the SQL statement as parameters to the Load function
- create the recordset within the Load function
- read the data into the arrays
- destroy the recordset
it seems to me that this would better emulate the way a recordset is created and filled with data, and would eliminate the need for the user to create his own recordset and then remember to destroy it.

ANSWER:
Good point. Makes a lot of sense, really. I suppose I did it out of my own remaining "timidness" to move entirely away from ADO recordsets myself! That is, I can still see them being created, and still have the job of destroying them...rather than trust that the VBScript class is doing it for me (even though I wrote the darned thing!). Sure, it make perfect sense to make the break complete, and let the class do all the housekeeping. Go for it.

QUESTION:
2) When you load a persisted ArraySet object with the LoadPersisted function, it only reads in the arFieldNames array. the Fields function attempts to access the field names through ad hoc variables created with Execute in the Load function. therefore, the Fields function will fail to ever find any data because these variables are not created in the LoadPersisted function. wouldn't you need to recreate them using a loop on the arFieldNames array?

ANSWER:
Good point, you spotted a bug that I somehow didn't test for. So, looking the code over and following your lead, I see I *did* the following...

- Create the arFieldNames array
- Load it with values from the recordset
- Generate the ad hoc variables with Execute()
- Save the arFieldNames array when persisting
- Load the arFieldNames array when reloading persisted data

...but did NOT do the following...

- Perform the Execute() statement on the arFieldNames array
when reloading persisted data

So, because the internals rely on the ad hoc variables created
with Execute when stepping through the records, reloaded ArraySets fail because there are no field-name values to work with.

If I've followed you correctly, then yes, this is a bug and needs to be fixed! Feel free to make up a little For/Next loop on the LoadPersisted method to do the job for yourself -- and it should work fine.

Great article. I had done something similar, just using arrays directly, but hadn't gone so far as to build an Arrayset class. Very straight-forward and very clean. I'm sure I'll be putting this to good use. I've looked all over for the source download you mentioned and could not find it, so I spent some time copying it out manually.

Anyway Thanks,

Space

I guess Tom doesn't follow this forum. Anyway, I just realized that
there is an additional problem with not being able to use multiple
Arraysets from the same or different tables on the same page, as
long as they have matching column names (like "ID").

It looks like the "strUniqueID" needs to be incorporated into the
ad-hoc variable names, otherwise you'll get an error attempting
to create two variables having the same name. This also must be
incorporated into the LoadPersist methods upon reloading.

I guess you could just get creative with the SQL "AS" statement ensuring the
columns never have the same names.

space