Keep small data available everywhere

[Andrzejek]

We have developed a large application in VB 6 for many offices, pretty much very custom app with a lot of Forms.

In many of the Forms we have to provide information, like County (one or two out of 100 of them), Work Codes (a couple out of over 200 of them) and some other information, usually just 2 columns of data: number and description.

In VB 6 I just kept a Global array (let’s say array CountyName) that I populated at the beginning of my app, and wherever I needed it in my code, I did:

If I have a County number 77, I just did:
CountyName(77) and that gave me the name of the County – Polk.

So I don’t have to go to my ORACLE database just to get this information.

I don’t know if that’s the best way to keep this information in VB.NET 2008
Would it be proper to keep it the same way, in a global array? (Arrays in VB.NET are 0 based, so some of my data would start with element 1011, leaving first 1010 elements empty ) I was also considering a separate Dataset just for these purposes.

Any suggestions are welcome.


Have fun.

---- Andy

 

[RiverGuy]

So I don't have to go to my ORACLE database just to get this information.

What's the reasoning on this? It's not a bad thing to query a database for a bit of information throughout an application.

Anyways, getting back to your basic question--a DataSet would be my choice to store these items. If the data is fairly static, then you can fill the DataSet once when the application loads, otherwise, refresh it when a new screen or control needs to interact with the data. Also, remember the importance of DataViews that you can apply to tables in the DataSet to filter context specific data.

 

[Andrzejek]

Thanks RiverGuy for supporting my idea of keeping info in a DataSet.

The reason I don’t really want to go to my database for just this small bit of info is – it is small and it IS static. And it is used often. It would be nice to have it available right there. For populating combo boxes, for example.


Have fun.

---- Andy

 

[gmmastros]

I do the same thing in my app, but with TONS of data.

What I do is... I load my data and set a local variable with the server's GetDate(). My tables have a trigger for update, insert, delete. The triggers update a config table with the date and time the change was made.

Then, whenever I use the data, I check this VERY small config table. If the ChangeDateTime is greater than the last time I loaded the data, I drop what's in memory and re-load from the database.

In my application, it's simply not practical to go to the database that often for such large amounts of data that rarely ever change.



-George

"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

 

[ousoonerjoe]

So I don't have to go to my ORACLE database just to get this information.

Unless these are Locked tables and are absolutely will not ever change, it would be wise to check them periodically to insure they have not been modified.

It never fails... the moment you think the state has the Counties set in stone, they change the way they number them. Or my personal favorite... A new city is formed and the State roster changes the numbering so all the city names are in order. Just things to be mindful of.

--------------------------------------------------
Bluto: What? Over? Did you say "over"? Nothing is over until we decide it is! Was it over when the Germans bombed Pearl Harbor? No!
Otter: Germans?
Boon: Forget it, he's rolling.
--------------------------------------------------

 

[Auguy]

I use a Globals class that can be used anywhere. I load the class with my values (properties) I want to have available throughout the app at startup. Then you just use these properties when you need them. As suggested before, for some values it would be wise to have the class re-query to get the latest values. Either way, you use the class the same way anywhere in the app.

Auguy
Northwest Ohio

 

[pmegan]

How about putting a public Hashtable or Dictionary in a module and storing you county ID/Names as key/value pairs in it? They're more efficient than datasets, the CountName(xx) syntax can still be used, and if you use a Generic Dictionary it will make sure your data types are correct.

You can store the county ID/Names in a database table and hit it with a datareader when the app loads to fill your list of counties. Put the procedure to load them in its own sub so you can call it periodically if the app is long running. Make the ID the primary key for the database table, or put a unique constraint on it, and you'll avoid having duplicates.