cashing information

[zeevgetner]

im writing buissness logic with vb, sql-server and mts.

i have some global information that doesn't change a lot.

would you advise me to build some kind of cashing system or
to keep accessing the database?

zeev

 

[VB400]

First, we'll assume that your data that's being returned from the MTS component is serialized into a string variable.

The best way to deal with this is to write out the serialized data to a local text file -- reading and writing to text files is ridiculously fast.

In the subroutine that would normally call the MTS component, you could do the following:

- Check if the local text file exists
- If it exists then check the date it was created
- If the date is older than current date or it simply doesn't exist then call the MTS component which should return the desired data.
- Once that data is returned from MTS, write it out to the text file

The following is sample code for a variation of this logic:


Public Function FetchLocal(FileName As String) As String

Dim strFile As String
Dim arBuffer() As Byte

strFile = App.Path & "\" & FileName & ".txt"

If FileLen(strFile) > 0 Then
Open strFile For Binary As #1
arBuffer = Space(FileLen(strFile))
Get #1, , arBuffer
Close #1
FetchLocal = arBuffer
Else
FetchLocal = ""
End If

End Function


Public Sub SaveLocal(FileName As String, Buffer As String)

Dim strFile As String
Dim rc As Long
Dim arBuffer() As Byte

strFile = App.Path & "\" & FileName & ".txt"
Kill strFile
Open strFile For Binary As #1
arBuffer = Buffer
Put #1, , arBuffer
Close #1

End Sub

You may need to put error handling as needed.

I hope this helps!

Tarek

The more I learn, the more I need to learn!

 

[chiph]

Also, you may want to read the info from the database when your MTS component starts up and keep it in memory (assuming your info isn't huge).

If that doesn't work, I'd think about keeping it in the database, depending on whether MTS and the database are on the same machine or not.

Tarek's idea of keeping it in a local file will certainly work, but it just seems.... I don't know... inelegant.

Chip H.

 

[palbano]

Tarek,

How would you accomplish synchronizing access to the file?

zeev,

Until you can accomplish synchronization of the information through some other mechanism I would continue to use the database.

"But, that's just my opinion... I could be wrong".
-pete

 

[VB400]

Pete,

The original question said "global information that doesn't change a lot" -- so my proposal was based on that.

Although the sample code doesn't show it, the preceding text talked about checking the date of the local file against current date. If the date the file was created is older than the current date then delete the local file and replace it with new data from the database. This insures that this file is refreshed daily. I think that for fairly static files like Department Master or Product Categories, this is not a problem. I certainly wouldn't do this for Customer Master, Purchase Orders or any such dynamic files.

Chip,

Keeping the data in memory (global variables) is certainly a valid option specially with today's hardware where memory, unlike the old days, seems to be a non-issue (well, almost):

If you have many of these types of files in an application then we'll eventually have to give memory usage a thought.

In today's ideology of "reusability", an object (such as a form) should not rely on (i.e. make direct reference to) global variables defined in another object. Otherwise, the object would have dependencies on other objects thus making it difficult to reuse.

If we opt for passing the "memorized" data as a parameter from one object to another then we would eliminate the direct dependency issue. However, it makes programming a bit more difficult. For example:

Form A uses the Departments List (objDepts)
Form B does NOT use it
Form C uses objDepts

If A calls B and B calls C then we would have to pass objDepts to Form B even if it doesn't make use of it other than pass it along to the next form. This, IMHO, is more inelegant.

The nice thing about the text file approach, is that the front end goes about its business requesting data from the Business Object, having no idea that the data has been cached in. All it knows is that when it needs a list of departments, it calls the corresponding Business Object which returns the requested data real fast.

There is hardly ever a situation where only one answer is the correct one.

Tarek

The more I learn, the more I need to learn!

 

[chiph]

Keeping the data in memory (global variables) is certainly a valid option specially with today's hardware where memory, unlike the old days, seems to be a non-issue (well, almost)

Yeah, memory's cheap! I just bought a 128mb SODIMM for the laptop, only eighty bucks from Crucial! I'd be showing my age if I mentioned that I can recall paying $14 per megabyte. I think Zeevgetner has to look at how much data he/she would want to keep in memory. A list of departments with names & addresses -- probably a bad idea. But a small table like ZIP code to US state look-up would be OK (this list is smaller than you might think -- only about 80 items)

There is hardly ever a situation where only one answer is the correct one.

True. I think Zeevgetner has to make a decision about how he wants to do this. Each approach thus far has some tradeoffs, and since we don't know all that much about his application, we can only suggest different approaches.

Chip H.

 

[VB400]

I clearly remember when it was $3x.00 per meg.

Tell you what, I won't tell anyone if you don't ;-)

Tarek

The more I learn, the more I need to learn!