CredLog PHYSICAL Table Structure
This page contains technical detail about the physical database structure. It is not required for normal day to day operation of the Point Of Sale.
Goto: Documentation Home
This table holds a log of all CRED identification blocks seen. A CRED block holds information about a users credentials and is created after the user has been authenticated
|GJ383M50FJ4J585H5||2-Jan-2015||10.47.80.194||Mozilla/5.0 (iPad; CPU OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F69 Safari/600.1.4|
|Physkey||string:44,zerolen||Required||100/s||Unique key assigned to this record|
|PhyskeyHash||long||101/E||Hash version of Physkey. This field can potentially have duplicates|
|RecDate||datetime||102/s||Date/Time this record was created|
|IPv4||long||120/E||IPv4 address in numeric form. This is the machines IP address, or if a network based client, the IP address of the remote system. If a proxy is in use, the address will be the source machine, not the proxy address|
|IPv4s||string:16,zerolen||121/E||IPv4 address (from above) in dotted ascii form|
|Tid||long||150/E||Pos Login Id#|
|Srcuid||long||151/E||Unique id referencing lane number|
|UserAgent||string:(big),zerolen||1300/s||UserAgent as supplied by Web Browsers. This value can be used to isolate type of browser being used. Some browsers allow their UserAgent strings to be altered, but this is unlikely to be seen in Intranet addresses|
|LoadFile||string:(255),zerolen||1600/s||Input file, if transactions are loading from a file|
Indexing❖ A unique primary key should exist on the physkey field.
❖ You may wish to index PhyskeyHash as an alternative for performance reasons.
The Fieldpine system does not generally read this table and does not rely on its contents. The data written here is to assist external reporting tools that may need this information.
This table will grow unbounded. You may need to implement archive policies. If you are extracting all information to an external system, it is acceptable to delete these records after a few days
As an example of grow rates, a typical record might be 200 bytes inside the database. A user will create a new CRED entry each time something changes. The same browser, on the same device, used all day by the same user will generally only create one CRED entry. Pos Users will create one CRED entry each. The daily volume is roughly
((# active pos users) + (# active non POS terminals)) * 200 bytesSo a system with 500 active staff members, spread over 100 stores, with 2 tablets in each store will generate around (( 500 ) + ( 2 * 100 )) * 200 bytes = 140KB/day.