Excellent. Like Kevin said, this does not protect table data but it will 
prevent someone from using forms if they cannot read/match employeeID 
and employee name stored in the library. Other sensitive data is broken 
up into other arrays, pw is additionaly stored as a hash.

Liz, the diff is that in one library the element is the name and the 
other the value part is the name. It appears that it does not matter 
which method used.

Thanks for your time guys.


On 03/09/2023 09:03 p.m., Liz McGuire wrote:
> I can read various bits of text when opening the Int.ldl in TextPad, for 
> example.  This includes things like "This program must be run under 
> Microsoft Windows", "Borland" various event and method names, and at the 
> end of the file, "Jack", "Jill", and "Sam".
> 
> I see the same sorts of things in Str.ldl - I'm not going to do a bit by 
> bit compare, but they look identical to my eye.
> 
> Liz
> 
> 
> On 09 Mar 2023 19:28, Peter wrote:
>> I have attached two delivered libraries with sample data containing 
>> employee name and ID number. Nothing else.
>>
>> I'm hoping someone has time to open each with a hex editor to let me 
>> know if they can see sensitive information. I tried but saw nothing 
>> other than the names, but I don't know much about hacking.
>>
>> Int.ldl
>> has a dynarray with three elements in the format
>> var dynint   dynarray[]smallint
>>
>> dynInt["Jack"] = 99
>> dynInt["Jill"] = 5
>> dynInt["Sam"] = 105
>>
>> The names can be seen but can the smallint value be seen?
>>
>>
>> Str.ldl
>> var dynname  dynarray[]string
>>
>> dynName[99] = "Jack"
>> dynName[5] = "Jill"
>> dynName[105] = "Sam"
>>
>> Again, the names can be seen but can the elements be seen?