Network Programming - Refreshing Listbox Browse

Network Programming - Refreshing Listbox Browse

Postby dpaterso » Thu Feb 23, 2006 7:28 am

How do I solve the following problem:

In a network environment:

Let us say that I have a workstation (workstation 1) that has a list of records being displayed at a given time and a user at another workstation (workstation 2) adds a new record to the same database.

At the moment the only time that the list being displayed on workstation 1 is updated to reflect the newly added record by workstation 2 is to exit the browse and then re-open the browse again and the new record appears.

I know I can add some sort of 'on right click of the mouse refresh the listbox or browse' but is there another way to either send a signal to all workstations on the network to update their browses or to use a timer of some sort like the 'on timer' thing?

If I ABSOLUTELY HAVE to use Define Timer .... (and there is no other way) then how do you equate the INTERVAL to seconds i.e. 60 seconds = what interval, 30 seconds = what interval? What is the formula?

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby dpaterso » Thu Feb 23, 2006 8:19 am

OK - I think I am getting very clever.

I have defined a timer with an interval of 100 that checks the CRC of the datafile and only if the CRC has changed will it refresh the listbox browse.

This works as any changes made on workstation 1 immediately update on the display of workstation 2.

My concern is this: what are the potential problems of using the TIMER if any? I did read somewhere not to make the interval too short for some or the other reason? What is a 'safe' timer interval to use? How do I know if the timer is causing a problem with the workstation / other apps / etc.?

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby Enrico Maria Giordano » Thu Feb 23, 2006 9:08 am

dpaterso wrote:I have defined a timer with an interval of 100 that checks the CRC of the datafile and only if the CRC has changed will it refresh the listbox browse.


100 means 0.1 seconds. I would use 1000 (1 second) to reduce the CPU usage.

EMG
User avatar
Enrico Maria Giordano
 
Posts: 8344
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia

Postby dpaterso » Thu Feb 23, 2006 9:23 am

Thanks a lot.

I have changed from 100 to 1000 and still works instantaneously.

I am so happy with this.

I have tested with 6 open browes so far - about another 10 to go (all MDI child windows) and they all update immediately as I make changes on another workstation.

If that's not enough this works perfectly on Windows '98 as well!!!

Thanks,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

How to check CRC of datafile?

Postby dutch » Thu Feb 23, 2006 12:22 pm

Dear Dale,

What does it mean "CRC of Datafile"? and
How do I check it (Which function)?

Thanks,
Dutch :?:
User avatar
dutch
 
Posts: 1535
Joined: Fri Oct 07, 2005 5:56 pm
Location: Thailand

Postby dpaterso » Thu Feb 23, 2006 2:29 pm

Hello Dutch,

There is a function called nFileCRC( ) that returns the Checksum of a file.

The Checksum of a file seems to change whenever any change is made to the file including just the simple flagging of a record for deletion.

e.g.

nFileCheckSum := nFileCRC( 'FILENAME.DBF' )

If you add, edit, delete, (anything), etc. etc. in FILENAME.DBF the Checksum changes so you can use this to check for changes to the file and update workstation displays if necessary.

I am using it so that I can accomplish the following:

Display Listbox Browse on Workstation 1
|
Create a Timer to check the Checksum of my database on Workstation 1.
|
If Workstation 2 makes a change to the the file the file Checksum has changed.
|
If the Checksum has changed then update my Listbox Browse on Workstation 1.

This stops the Listbox Browse being visibly updated every time the Timer checks for changes to the file i.e. the Listbox Browse is only visibly updated / refreshed / repainted / whatever if a change has been made to the database file.

I am very proud of this code so feel free to ask for a copy.

It makes the Listbox Browses update on all workstations on the network 'as if by magic' :).

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby James Bott » Thu Feb 23, 2006 3:18 pm

Dale,

Correct me if I am wrong, but doesn't a checksum require reading the entire file? I don't think this is feasible.

Why not just check the file time?

James
User avatar
James Bott
 
Posts: 4840
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA

Postby dpaterso » Thu Feb 23, 2006 3:44 pm

Hello, as you can see I have been working hard today!

I actually couldn't tell you if it reads the entire file or not BUT if you are right then I am heading for a disaster as I am only using test data for now which never amounts to more than a couple of records in a file.

I will do a REAL test and create a .dbf with lots and lots of records and then see if my code works / slows down.

I am kind of hoping that it reads or creates a checksum from the header though. Anyone know anything more about this? Anywhere I can look for more technical information on nFileCRC( )?

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby dpaterso » Thu Feb 23, 2006 4:17 pm

OK, OK, OK!

As always - you are right!

nFileCRC( ) OBVIOUSLY reads the entire file because with 50000 records the system becomes unuseable i.e. every time the timer ticks the system stalls for a time and then comes back to life!!!!!!

Back to the drawing board :x

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby James Bott » Thu Feb 23, 2006 4:26 pm

Dale,

I know, I can be a real PITA.

Just try using the file time. Unless users will be working across midnight you don't need to use the date too, although that would be safer.

I would use a longer interval also, 5 seconds maybe. That will also reduce the traffic considerably over 1 second.

James
User avatar
James Bott
 
Posts: 4840
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA

Postby dpaterso » Thu Feb 23, 2006 5:00 pm

Thanks for the advice.

I will have to test it though because I am not entirely sure that a file's date and time are changed until a user actually closes the file (at least not on a Novell network anyway).

In other words there would be a difference between the time that the file was last accessed, last modified, and created, and I not sure what our FWH functions pick up.

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby dpaterso » Thu Feb 23, 2006 8:11 pm

Hi,

Just tried using the File Time and no go i.e. on Novell Netware the Date and Time of a file only gets updated when that file is closed by the user that made the change (I have even tried - liberally - DBCOmmits() all over the place - no go.

Does anyone know of a function that will read a DBF header? I mean the file header MUST contain some sort of information or other with regard to no of records, no of deleted records, and other info.

If it is possible to access this information then one could write their own sort of nDBFHeaderCRC( ) function or something like that.

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby dpaterso » Thu Feb 23, 2006 8:32 pm

OK, well I found out what the header holds and there is no time, only the date of the last update.

Thoughts?

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Postby Enrico Maria Giordano » Thu Feb 23, 2006 8:49 pm

dpaterso wrote:Just tried using the File Time and no go i.e. on Novell Netware the Date and Time of a file only gets updated when that file is closed by the user that made the change


Are you sure? Have you really checked the file properties after a COMMIT?

EMG
User avatar
Enrico Maria Giordano
 
Posts: 8344
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia

Postby dpaterso » Thu Feb 23, 2006 9:43 pm

I just realised something (after posting two possible solutions, then realising that I was talking you know what, and deleting the supposed solutions).

The Novell Client software has a property called 'File Commit' (or 'True Commit' for the Windows 95/98 Client) and its description is as follows:

'Controls whether buffers flushed by an application are committed to disk on the server. Setting this value to On will ensure data integrity at the expense of performance by ensuring file buffers are committed to disk on the server when an application flushes its file buffers.'

I will change and test in the morning and post results.

Regards,

Dale.
dpaterso
 
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa

Next

Return to FiveWin for Harbour/xHarbour

Who is online

Users browsing this forum: Google [Bot] and 35 guests