I have been working with some legacy code at work. There seems to be a common logic in storing an entire table in the database as an array. I have got no clue at all as to why this needs to be done. The recordet is open the entire time the application is loaded. There are options like "Seek", "Find" or even write a query to get what you want. I do not see the need to copy the entire array into an array. I was wondering if anyone here can shed some light on this. Is it quicker than reading from an mdb?
In some cases, it's just better to accept what's there and don't try to judge or try to figure out WHY they did what they did. Otherwise, we'd be second-guessing without the benefit of knowing what the situation was when it was written.
Perhaps when it was written, there was a network latency issue. Who knows? Depending on "how legacy" your legacy app is (as in, written decades ago) it is entirely possible the author simply wasn't that good at writing VB.
Without knowing more about the app, there isn't much we can do for you. There are of course many questions to ask, and many considerations.
If it's reference data he's loading into an array, it could probably be done more easily with a recordset clone. If he was retrieving the data and disconnecting from the database, again it would be easier to just load it into an in-memory recordset object.
The only possible reason I could think of is if he's just reading the entire recordset sequentially multiple times during the life of the execution. Even with that, there's no substantial difference in performance on today's machines.
If you can improve it without breaking the app, great. Otherwise, just shake your head, roll your eyes, and try not to be too harsh when you talk about it. After all, some time years from now someone might be doing the same thing with YOUR code! :-)