|
FAQ |
|
|
|
FAQ |
|
This page contains a list of Frequently Asked Questions for PostgreSQL Data Access Components.
If you have encounter a question with using PgDAC, please browse through this list first. If this page does not answer your question, refer to the Getting Support topic in PgDAC help.
Installation and Deployment
You may be having a compatibility issue that shows up in one or more of the following forms:
You can have such problems if you installed incompatible PgDAC, SDAC, ODAC or IBDAC versions. All these products use common base packages. The easiest way to avoid the problem is to uninstall all installed DAC products and then download from our site and install the last builds.
Usually, you do not need any additional files. The only exceptions to this rule are listed below:
You are using TPgConnection.Options.Direct := False mode and the client library is not
available for your application.
Windows: You should copy client file PostgreSQL client library to a folder available to the executable unit of your program.
For example, to the folder containing the executable or to the Windows system folder. For more details, see the
description of LoadLibrary and the PATH environment variable.
Linux: You should copy the client file libPostgreSQLclient.so.X to the folder available to the executable unit of
your program. For more details, see the description of the dlopen function and the LD_LIBRARY_PATH environment
variable.
If you have purchased a full version of PgDAC, you are entitled to distribute pre-compiled programs created with its use. You are not entitled to propagate any components inherited from PgDAC or using PgDAC source code. For more information see the License.rtf file in your PgDAC installation directory.
You can create your own components that are inherited from PgDAC or that use the PgDAC source code. You are entitled to sell and distribute compiled application executables that use such components, but not their source code and not the components themselves.
All upgrades to future versions are free to users with an active PgDAC Subscription.
The PgDAC Subscription Program is an annual maintenance and support service for PgDAC users.
Users with a valid PgDAC Subscription get the following benefits:
Priority Support is an advanced product support program which offers you expedited individual assistance with PgDAC-related questions from the PgDAC developers themselves. Priority Support is carried out over email and has a two business day response policy.
Yes, you can. PgDAC version licenses are perpetual.
An annual PgDAC Subscription is included when ordering or upgrading to any registered (non-Trial) edition of PgDAC.
You can renew your PgDAC Subscription on the PgDAC Ordering Page. For more information, please contact [email protected].
To upgrade to new PgDAC versions, you can get a Version Update from the PgDAC Ordering Page. For more information, please contact [email protected].
PgDAC uses a low-level protocol to access the database server. This allows PgDAC to achieve high performance. From time to time we compare PgDAC with other products, and PgDAC always takes first place.
Locate is performed on the client. So if you had set FetchAll to False when opening your dataset, cached only some of the rows on the client, and then invoked Locate, PgDAC will have to fetch all the remaining rows from the server before performing the operation. On subsequent calls, Locate should work much faster.
If the Locate method keeps working slowly on subsequent calls or you are working with FetchAll=True, try the following. Perform local sorting by a field that is used in the Locate method. Just assign corresponding field name to the IndexFieldNames property.
You can determine your PgDAC version number in several ways:
Just set the DBAccess.ChangeCursor variable to False anywhere in your program. The cursor will stop changing after this command is executed.
The values of these properties are templates for query statements, and they cannot be manually executed. Usually there is no need to fill these properties because the text of the query is generated automatically.
In special cases, you can set these properties to perform more complicated processing during a query. These properties are automatically processed by PgDAC during the execution of the Post, Delete, or RefreshRecord methods, and are used to construct the query to the server. Their values can contain parameters with names of fields in the underlying data source, which will be later replaced by appropriate data values.
For example, you can use the SQLInsert template to insert a row into a query instance as follows.
The value of the SQLInsert property will then be used by PgDAC to perform the last step.
Setting these properties is optional and allows you to automatically execute additional SQL statements, add calls to stored procedures and functions, check input parameters, and/or store comments during query execution. If these properties are not set, the PgDAC dataset object will generate the query itself using the appropriate insert, update, delete, or refresh record syntax.
Use the TPgConnection.GetDatabaseNames method.
The following situations usually arise from the same problem:
To fix this, you should add the PgDACVcl (for Windows) or PgDACClx (for Linux) unit to the uses clause of your project.
DbxMda is our dbExpress driver for PostgreSQL. dbExpress technology serves for providing a more or less uniform way to access different servers (SQL Server, PostgreSQL, Oracle and so on). It is based on drivers that include server-specific features. Like any universal tool, in many specialized cases dbExpress providers lose some functionality. For example, the dbExpress design-time is quite poor and cannot be expanded.
PgDAC is a specialized set of components for PostgreSQL, which has advanced server-specific design-time and a component interface similar to that of BDE.
We tried to include maximal support of PostgreSQL-specific features in both DbxMda and PgDAC. However, the nature of dbExpress technology has some insurmountable restrictions. For example, Unicode fields cannot be passed from a driver to dbExpress.
PgDAC and DbxMda use the same kernel and thus have similar performance. In some cases dbExpress is slower because data undergoes additional conversion to correspond to dbExpress standards.
To summarise, if it is important for you to be able to quickly adapt your application to a database server other than PostgreSQL, it is probably better to use DbxMda. In other cases, especially when migrating from BDE or ADO, you should use PgDAC.
Yes, PgDAC is thread-safe but there is a restriction. The same TPgConnection object cannot be used in several threads. So if you have a multithreaded application, you should have a TPgConnection object for each thread that uses PgDAC.
We always try to keep PgDAC compatible with previous versions, but sometimes we have to change behaviour of PgDAC in order to enhance its functionality, or avoid bugs. If either of changes is undesirable for your application, and you want to save the old behaviour, please refer to the "Compatibility with previous versions" topic in PgDAC help. This topic describes such changes, and how to revert to the old PgDAC behaviour.
This error occurs when the database server is unable to determine which record to modify or delete. In other words, there are either more than one record or no records that suit the UPDATE criteria. Such situation can happen when you omit the unique field in a SELECT statement (TCustomDADataSet.SQL) or when another user modifies the table simultaneously. This exception can be suppressed. Refer to TCustomPgDataSet.Options.StrictUpdate topic in PgDAC help for more information.
Fields of this type are represented in Delphi by TLargeIntField objects. In some versions of Delphi, you cannot access these fields through the Value property (for more information see the SetVarValue protected method of TLargeintField in the DB unit). To avoid this problem, you can change the field type to INT, which is usually sufficient for key fields. Alternatively, you can avoid using Value.
For master/detail relationships the problem can be avoided only by changing type of the key field to INT, as Delphi's master/detail mechanism works through Field.Value.
First of all, you should find out what causes the problem. The list of most frequent reasons for this error to occur is below.
If the connection is lost, PgDAC tries to reconnect to server. However, your last command will probably not be executed, and you should repeat it again. PgDAC does not try to reconnect if a transaction has started or if at least one of statements is prepared.
The following problems may appear when using FetchAll=False mode:
Usage of FetchAll=False mode has many advantages; however, it also has some restrictions since it requires an additional connection to server for data fetching to be created. The additional connection is created to prevent the main connection from blocking.
These problems can be avoided by setting the FetchAll property. Please see description of the FetchAll propery and the CreateConnection option in PgDAC help for more information.
PgStoredProc.Prepare;
PgStoredProc.Open;
PgStoredProc.UnPrepare;
PgStoredProc.Prepare;