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

Example Rows

Physkey	RecDate	IPv4s	Srcuid	Tid	UserAgent
VBR74B5I3954B5H47	1-Jan-2015	10.23.0.16	1203	72
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

Columns

FieldName	Datatype	Meta Info	Gnap	Description
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.

Remarks

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 bytes

So 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.