Database.

PrintFaqtory supports, as it’s backend database, Microsoft’s SQL Server 2000 or better, Oracle 8/9i and MySQL. Microsoft SQL Server Data Engine and MySQL are included free with PrintFaqtory (CD version only). MySQL is the recommended database for PrintFaqtory as, in this type of application, it is several orders of magnitude faster than either SQL Server or Oracle and requires dramatically less system resources.

See Integration for details of interfacing to other databases (Access, FoxPro, ODBC etc.)

The database can be changed at any time from the screen below (from the main menu, Setup>Data Source).

Above are PrintFaqtory’s main tables (Header, abbreviated to ‘HDR’ and Line, abbreviated to ‘LNE’) before any fields have been defined. DocumentNo (auto number in the Header table) is the primary relationship between these tables. Other fields are as follows:

Header Table (T_HDR_’Document Name’).

• Status (char 20). This field is provided for when PrintFaqtory is integrated with another system to show the record’s update status. Default ‘Ready’.
• Source (char 20). This field contains the name of the input source that received the report. Values are Comm1 to 255, NSC1 to 1000, NFM1 to 1000, Network Printer and Reprocess. Used if several Instruments/PLCs are producing exactly the same report and there is no other way of identifying the report.
• TmeStmp (timestamp). This field contains the DateTime that the report was printed.

Line Table (T_LNE_’Document Name’).

• DocumentNo (number). The field that relates the record to the Header table.
• LineNumber (number). Sequential Line Number (1 based) for maintaining the sequence of Line Item records.

An example of the main tables after fields have been defined.

Database Description.

Other Tables.

Document Type.

Fields for this table are defined by the ‘Doc Definition’ tab.

Template.

This table describes the fields for building the Header/Line tables.

Line Input Properties.

This table describes the sections of the report that are to be removed before the report is processed i.e. page breaks.

Alarm Defintions.

This table is for detecting alarm data in Tag reports.

Alarm.

This table stores the alarms for each Tag report, as defined by the Alarm Definitions table above.

History.

Tag history data.

(C) 2003 John Burch Read our Privacy Policy