Skip to content
← Customer Feedback for Devart

Delphi Data Access Components

Delphi Data Access Components is a line of DB connectivity solutions for such databases as: Oracle, Microsoft SQL Server, MySQL, InterBase, Firebird, PostgreSQL, SQLite, Microsoft Access, DB2, Sybase Advantage Database Server, Sybase Adaptive Server Enterprise, and other databases (using ODBC provider).

http://www.devart.com/dac.html

Delphi Data Access Components

Categories

JUMP TO ANOTHER FORUM

(thinking…)

How can we improve our Delphi Data Access Components?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

10 results found

  1. Implement COPY FROM/TO functionality

    Implement COPY FROM/TO functionality for PostgreSQL (PgDAC component).

    PostgreSQL COPY manual:
    http://www.postgresql.org/docs/current/interactive/sql-copy.html

    103 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    1 comment  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  2. Retrieving Query Results Row-By-Row

    PostgreSQL 9.2 has a new feature that allows results sets to be returned row by row instead of the whole result set at once.
    This is a huge improvement for larger result sets.
    See here for more info:
    http://www.postgresql.org/docs/9.2/static/libpq-single-row-mode.html

    14 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  3. Support PostGIS Geometry-Data-Types

    The possibility to read/write Geometry-Data-Types of PostGIS (MultiPolygon, Collections etc.) as it is possible with PostGreSQL-Geometry-Data-Types like lseg, polygon etc.

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  4. Support Postgres Advanced Server

    Postgres Advanced Server (PAS) is an extended version of PostgreSQL, it supports Stored Procedures, Packages and Aliasses. Currently, PgDAC does not support executing several of the commands available in PAS.

    6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  5. Support for OpenSSL 1.1

    UniDAC currently only supports OpenSSL 1.0.2. This version won't be supported past 2019-Dec-31.

    To avoid problems UniDAC should support OpenSSL 1.1

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  6. Support inherited tables on the TPgDump component of PgDAC

    Actually (v6.2.4), the PgDac TPgDump component does not generate appropriate code for inherited tables, making it useless when inherited tables are used, and we need to get the SQL script to generate the given schema.

    TPgDump should support tables inheritance and:
    - create base tables before inherited tables
    - use the inherits clause within the table creation sql statement
    - do not generate insert statements for base tables data, only for inherited tables

    Thanks,

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  7. Support GENERATED ALWAYS AS XXX STORED-Columns

    In Postgres it's possible to create an readonly column,

    See
    https://www.postgresql.org/docs/current/sql-createtable.html

    GENERATED ALWAYS AS ( generation_expr ) STORED
    This clause creates the column as a generated column. The column cannot be written to, and when read the result of the specified expression will be returned.

    Automatic generated SQL for INSERT OR UPDATE don't handle the column as readonly. If you set UpdateAllFields to true an exception is raised. Also an exception occurs when you change the value of this field an call Post.

    The column should be set to readonly an the corresponding field should be excluded from INSERT andUPDATE.

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  8. Export SQL from Query component with values of the parameters

    When you need to debug some SQL, you can save the SQL query to a file and then run it outside of your application to check for any issues with the query. However, you cannot do the same when using parameters. When you try to save SQL.Text to a file, you will get the query with parameter names, such as SELECT * FROM A WHERE Id = :paramname. To debug effectively, I need to see the values of the parameters. Ideally, I want to save the query with the actual parameter values, like SELECT * FROM A WHERE ID =…

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  9. Add refreshquick to PgDAC

    The RefreshQuick method (https://www.devart.com/mydac/docs/devart.mydac.tcustommydataset.refreshquick(system.boolean).htm) seems very useful to refresh only the new records from big datasets. Ideally, make it possible to specify the name of the TIMESTAMP field so we don't have to create a duplicate - mine are called "created" for example). Maybe we don't even need the TimeStamp field for Postgresql ?

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  10. Add PostgreSQL error codes to error message

    Currently we are migrating Oracle to PostgreSQL DBExpress. With Oracle, we were able to categorize DBExpress errors based on the message "ORA-XXXXX" and perform appropriate error handling. We had to do this because of the limitation of DBExpress.

    With PostgreSQL, we have the problem that we only get the error message. So we would have to parse all error messages individually. Per error code there are 1:n different PostgreSQL error messages!

    Therefore our question to you: Would it be possible to set the error code analog to Oracle at the start of the error message?

    For example "PG-22023 input string…

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    1 comment  ·  PostgreSQL  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
  • Don't see your idea?