Database development and training for Birmingham and the midlands
Specialists in Microsoft Access and Visual Foxpro database training and development
I am happy to hear from existing clients but I am taking no new calls.
Generating a CheckSum
A CheckSum is a single number that acts as a signature for a larger amount of data. Its original use was to provide a way of checking that a message had been transmitted correctly across an unreliable link. The checksum would be calculated by the sender and sent in the same transmission as the text of the message. The receiver would then recalculate the checksum of the text received and compare this with the checksum transmitted. If the two numbers matched then that would indicate that the message had very probably been received correctly. If they did not match then either the message or the CheckSum must have been corrupted and the recipient would request a repeat transmission.
FoxPro provides two Sys functions which you can use to generate a checksum as a 16-bit or 32-bit number. One of these functions bases the checksum on a string of text, the other works from a complete record.
Use the Sys (2007) function to generate a 16-bit or 32-bit CheckSum from a string:
will print "10376", the 16-bit checksum of the word "Test". Note that this is a string of digits, not an integer.
Pass two extra parameters to Sys(2007) to generate a 32-bit checksum:
This will print "2018365746", the 32-bit checksum of the word "Test". This too is a numeric string, not an integer.
Note that both checksum algorithms are case-sensitive because they are dealing with the ASCII representation of the characters. The 16-bit checksum for the word "test" is "8134" rather than the "10376" that was calculated for "Test".
You can improve the security of your application by storing the checksum of a password instead of the password itself. When the user logs in, take the checksum of the password they enter and compare it with the number stored in the login table.
Using a checksum in this way means that nobody - not even the developer - can read the login table and see a user's password in plain view. If the intruder does have a copy of FoxPro and if they have plenty of time to spare then they could try calculating the checksums of all the likely passwords. This is a long job but not a totally impossible one so do not rely on this simple technique if your system must have absolute security.
Use the Sys(2017) function to generate a CheckSum from the current record inthe current work area:
You can use this function to detect unauthorised changes to data. Add an extra field to the table and use Sys(2017) to calculate the checksum whenever a record is added or modified. Any authorised change to the data will be matched by a change to the stored value of the checksum. If the checksum does not match then the data must have been changed by somebody who was not using the correct data entry forms.
Another use for Sys (2007) is to detect whether the user has made any changes to the current record. If you take the CheckSum as the form loads and again when the user tries to close it then any change in any of the fields will show up as a change in the value of the checksum. If the 'before' and 'after' values are the same then no changes have been made to the data. You can use the GetFldState() function to give this information for buffered tables but that will record a change if the user edits a field and then undoes the alteration so that the record actually remains unchanged.
The Sys(2017) function can take extra parameters to define which named fields are to be included in the calculation and whether or not Memo fields are to be included.