General Considerations
Here are some general considerations in regards to PlanetPress Capture, its environment, the hardware and the software that interacts with it. Please review these considerations carefully as they may impact PlanetPress Capture and its functionality.
PlanetPress Capture Fields cannot simply be inserted into an existing document as-is and expected to work properly, efficiently or consistently. In order to design a document with Capture Fields, you must review and understand the Critical PlanetPress Capture Implementation Restrictions.
Database Considerations (ODBC)
On 64-bit operating systems, the ODBC Data Sources created by the Data Source (ODBC) icon in the Administrative Tools will not appear here, as PlanetPress Suite is 32-bit and cannot access the 64-bit data sources. In order to create an ODBC connection visible by PlanetPress, you will need to access the 32-bit version of the ODBC manager, available in C:\Windows\SysWOW64\odbcad32.exe .
The following considerations should be kept in mind while working with ODBC Databases in PlanetPress Suite.
- All databases
- User Rights: During normal operation, Read/Write to tables should be sufficient. However, during the initial setup, the Create/Drop tables rights is necessary.
- Minimum 100MB of database size is required as a minimum, but the space requirement is dependant on the implementation. The more active documents in the database, the more space is used - note that this progression is rather linear.
- Regular database maintenance is required, such as database compacting, is required by a system administrator.
- It is recommended to create an IT process that backs up the database regularly.
- The recommended ideal setup is a dedicated SQL Server PC, accessed by PReS™ Workflow through an ODBC connection on the local network.
- Microsoft Access
- Database file (mdb) must be local to the PlanetPress Workflow computer. It cannot be located on a network drive or another server.
- Total database size is limited to 4GB of data.
- Total size of a single table is 2GB.
- May be unstable in large implementations.
- MySQL
- Database can be in any location, but performance will depend on the speed of the connection between PlanetPress and the MySQL server.
- MySQL's performance has been slower than SQL Server and SQL Server Express during our tests.
- By default, MySQL is configured not to allow any SQL request larger than 16 megs.
- In the event where 2 requests are made simultaneously on the same record, MySQL will queue one of the requests and execute it once the first one is done. In extremely rare cases this may cause a timeout on very large requests.
- MSSQL (Microsoft SQL Server)
- All versions of the SQL Server are supported, including all Express versions.
- Database can be in any location, but performance will depend on the speed of the connection between PlanetPress Production and the SQL server.
- In the event where 2 requests are made simultaneously on the same record, SQL Server will drop the most complex request. Resubmitting the PGC for processing should resolve this issue. This, however, should happen only rarely.
- When configuring the ODBC connection, your must use the Microsoft version of the driver, and not the Native SQL version of the driver. This is due to a technical limitation of the native driver that interferes with the PlanetPress Suite database requests.
Specifically for PlanetPress Capture, these considerations mean the following:
- In Microsoft Access, the total size of stored document cannot be larger than 2GB and this database will be very unstable in implementation with more than a few thousand pattern sequences being used simultaneously. It is only suggested for small implementation with less than 10 pens, or for demos.
- In MySQL, the 16 megs packet size limit can be an issue if the PDFs created by Capture are larger than this size; An error saying "MySQL Server has gone away" would appear in this case. This can be fixed by configuring the max_allowed_packet setting in the MySQL Configuration (Reference).
- Also in MySQL, if a timeout occurs on simultaneous record access, resubmitting the PGC for processing should resolve the issue.
- In SQL Server, if one of your requests is dropped because of simultaneous accesses, resubmitting the PGC should resolve the issue.