Why/when should I consider using Portfolio SQL Connect?

... if you answer "Yes" to any of the following:

1. Does your company currently use an SQL database from Microsoft SQL Server, Oracle, or MySQL?
2. Do you have the need now (or in the near future) to manage 100,000 or more assets?
3. Do you have multiple users adding or updating catalogued items from your database at high frequency?
4. Do you have multiple users and/or NetPublish web users running complex queries at high frequency?
5. Do you need the ability to build custom reports and database queries?
6. Do you need to operate in a thin client environment?
7. Do you need a read/write web interface?

Notes
1. Does your company currently use an SQL database from Microsoft SQL Server, Oracle, or MySQL? To use SQLConnect you will need to be using - or to acquire - on of the supported SQL types. For Windows this is Microsoft SQL Server, Oracle, or MySQL and on Mac, just MySQL. If there is a choice of server OS, general experience is that Win/SQLServer is the best combo (Oracle is in a cost/performance bracket of its own). For those who already own/operate SQL infrastructure, it can be simpler to use SQL from outset simply because then much of the back-up activity and IT support draws on existing resources. Conversely, for smaller organisations with no existing SQL expertise, the cost of equipment, software beyond Portfolio components, and support must be considered.

2. Do you have the need now (or in the near future) to manage 100,000 or more assets? Your FDB (single file) catalogues for stand-alone or Portfolio server use can be up to 4 GB in size and certainly exceed 100,000 records. However, in a multi-user scenario it is the combination of catalogue size and the concurrent activity of #3/#4 above that may push you to needing SQL. A single user on a powerful (CPU/RAM) desktop can happily work with large FDBs above 100,000 records. Even so, issues like doing backups may make a move to SQL a sensible choice.

3. Do you have multiple users adding or updating catalogued items from your database at high frequency? Using a server for Portfolio use and employing server auto-synch may keep this as a less likely upgrade factor than #2/#4#/5.

4. Do you have multiple users and/or NetPublish web users running complex queries at high frequency? Whereas client queries allow a maximum 5 query parameter sets, the NetPublish (NP) interface allows for more (via custom coding). Bigger queries - with more parameter sets per query - mixed with high traffic rates will have an impact on performance.

5. Do you need the ability to build custom reports and database queries? Portfolio client & NP queries are interpreted left-to-right and don't allow for advanced query aspects like nested clauses. These can be accommodated if written as direct SQL queries of an SQL Connect catalogue. In addition the IT underpinnings of an SQL set-up means it is generally better equipped to handle the performance impact of complex SQL queries.

6. Do you need to operate in a thin client environment? If your desktop environment is locked down or contractually controlled, installing clients may be a non-trivial issue.

7. Do you need a read/write web interface? NP provides a rich web interface, but it is read/only. To allow data entry via a web browser requires an SQL-based catalogue as then the web pages can 'talk' to the database directly via SQL calls. Some third-party solutions exist for this particular aspect of SQL access making it easier for non-SQL savvy outfits to get such a solution up and running.

Also read the document "Portfolio SQL Connect Technical Overview" (P8SQL_TechO_1006.pdf) obtainable from Extensis.

Question: Why/when should I consider using Portfolio SQL Connect? [FAQ00389.htm]
Last Update:- 26 March 2007

This FAQ is created and maintained using

Friday - The Automatic FAQ Maker