Our application successfully communicates with various databases (MSSQL, Oracle, Firebird) via ADO, that's why I'm trying to use ADO to add the PostgreSQL option to our software. I use standard PostgreSQL ODBC provider. All was fine until I faced with the problem with the large TEXT fields. When I use Unicode version of the provider and try to get TEXT field AsString, the application is just crushed with EAccessViolation in method RemoveMediumFreeBlock(). ANSI version works, but it cuts the content of the field (I guess the characters besides default 8190 LongVarChar limit). Small TEXT fields are read OK.
Could you suggest me what to do with this issue?
Is there the better option to work with PostgreSQL via ADO in Delphi?
Related
I have an agent written in Lotuscript (IBM Domino 9.0.1 - Windows 10) that reads records into a DB2 database and writes them to Notes documents. The table in DB2 (Centos OS) contains international names in Varchar fields such as "Łódź".
The DB2 database was created as UTF-8 CodePage: 1208 and Domino by its nature supports UNICODE. Unfortunately, the value loaded in the notes document is not "Łódź" as it should be but it is "? Ód?".
How can I import special characters from DB2
in Domino NSF DBs in correct ways?
Thank you
To import the table I used the following code taken from OpenNtfs XSnippets:
https://openntf.org/XSnippets.nsf/snippet.xsp?id=db2-run-from-lotusscript-into-notes-form
Find where the codepage conversion is happening. Alter the lotusscript to dump the hex of the received data for the column-concerned to a file or in a dialog-box. If the hex codes differ from what is in the column, then it may be your Db2-client that is using the wrong codepage. Are you aware of the DB2CODEPAGE environment variable for Windows? That might help if it is the Db2-client that is doing the codepage conversion.
i.e setting environment variable DB2CODEPAGE=1208 may help, although careful testing is required to ensure it does not cause other symptoms that are mentioned online.
Using Rational Application Developer for Websphere 9.1.0 to make a data connection to a DB2 iseries file, the column data displays a Hex(I think).
I have added the "translateBinary=true" property to the url connection but is does not change the display results.
jdbc:as400:host;translateBinary=true
DB2 for iSeries uses EBCDIC natively but the Toolbox JDBC driver will automatically attempt to translate EBCDIC to unicode for you. Since only some fields are not being translated, it is likely those fields are tagged with CCSID 65535 indicating to the Toolbox driver not to translate them. You can either tag those fields with a CCSID indicating to translate, or use the translate binary driver property, which you're attempting to. The property is not working because you mis-typed it. According to this faq, it should be ";translate binary=true" instead of what you've tried.
Working with PostgreSQL, DataGrip converts all names of created tables/columns to lowercase. How to disable it and keep original formatting? I prefer PascalCase.
It happens even if I run a SQL command manually in DataGrip console:
create table FooBar();
so the table foobar is created in db. I searched across the web and found nothing. I suppose it is not a PostgreSQL problem because pgAdmin3 doesn't change anything when it's doing the same things.
My environment:
Windows 7 Pro
DataGrip 2016.3.4
PostgreSQL 9.4
This is a Postgres feature, DataGrip has nothing to this issue.
If you want "PascalCaseIdentifiers" you have to use double quotes.
Identifiers without quotes are case-insensitive. They are automatically converted to lower case.
Read about details in the documentation.
pgAdmin3 doesn't change anything when it's doing the same things.
Quite the opposite, pgAdmin3 adds double quotes when e.g. an identifier contains capital letters (see the last tab SQL in New table... dialog).
In my (and not only my) honest opinion, using quoted identifiers is in general a very bad idea. It simply creates more problems then they are worth it.
This is a hybrid question & public service announcement. The basic question is whether there are convenient and/or efficient workarounds to the limitations listed below. I spent half the morning discovering that one cannot just transplant SQL code from Access to Matlab. I've boiled it down to 3 points so far.
Can't use double quotes in SQL statements to avoid collision with
Matlab's string delimiter. The Matlab code for the SQL code strings
can become quite complicated, especially if the SQL strings already
use repeated single-quotes to represent a single quote within a
string constant.
Must always specify a source table from which to query. What won't
work is "SELECT #2015-07-28#". One basically needs to create a 1-row dummy table.
Must always select at least one field in the table being queried.
An asterisk does not seem to suffice.
The above limitations do not exist when submitting SQL code using the Access Query Designer (either in SQL 92 mode or not), nor do these limitations exist when submitting SQL code using VBA via CurrentProject.Connection.Execute.
Hopefully, this saves someone else some time in learning about these differences. And if anyone has found a workaround, that would be appreciated. Note that the above is in the context of using the JDBC/ODBC bridge (3rd of 3 illustrated configurations in the drivers documentation. The database toolbox documentation for directly connecting to an Access file using code (rather than setting up a data source using the GUI) only describes a code pattern that uses the JDBC/ODBC bridge. This is described in Example "Connect to Microsoft Access Using a File DSN" in the "Connect to database" page. I'd like to stick to this approach because I want to quickly be able to directly specify the source *.accdb file without jumping through GUI hoops of setting up a data source.
I've posted this to:
Stack overflow
Usenet
While I have not connected Matlab to Access, I have connected Access databases to PHP, Python, SAS, R, even Excel without any issues with quotes or asterisk. As for the needed source table in queries that is simply due to the Jet/ACE SQL dialect as each dialect have their particular rules. But your query above should work for one-row, one-column output of such date. SQL Server does not require a source table but Oracle does. Access dates are in the MM/DD/YYYY format, requiring # in conditional statements. MySQL use dates in YYYY-MM-DD format, requiring single quotes.
Are you using Windows installed Jet/ACE ODBC drivers? Do note these drivers are softwares external to any application (not part of Access) and can be used by any client interfacing to any data source. Aside - many are not aware that Access' backend database engine, Jet/ACE is actually a Windows technology and not restricted to Access; PC users without Access installed can still use this engine. Hence, connection strings are standard across ODBC calls. And as I see you can apply same principles to Matlab database connections.
With that said, my suggestions/workarounds:
properly learn the SQL dialect for connecting database and check if query runs; even optimize or re-write as needed
try escaping various punctuation not compliant in Matlab strings or use the ASCII counterparts: chr(34) for double quote; chr(39) for single quote; chr(42) for asterisk.
if select statements are limited in Matlab strings, create a temp table from query (use make-table query SELECT * INTO newtable FROM query outside of Matlab), then connect to this new table
use intermediary coding language (VBA, Python, C#) by user trigger or
command line to connect to database and export needed dataset, then
automate Matlab to import
export query to flatfile format (csv, txt, etc.) for Matlab import
The project which I am working now is upgrading the database from mysql to postgreSQL in Zend framework. I had migrated the database to PostgreSQL through "ESF Database Migration Toolkit". How ever the field names like "Emp_FirstName", "Emp_LastName" etc are stored in PostgreSQL as "emp_firstname" and "emp_lastname". This caused Errors in code. However when I updated the filed in PostgreSQL to Emp_FirstName it showing error
********** Error **********
ERROR: column "Emp_FirstName" does not exist
SQL state: 42703
Character: 8
Is it possible to give filed name exactly like in MYSQL?
The migration tool isn't "double quoting" identifiers, so their case is being flattened to lower-case by PostgreSQL. Your code must be quoting the identifiers so they're case-preserved. PostgreSQL is case sensitive and case-flattens unquoted identifiers, wheras MySQL is case-insensitive on Windows and Mac and case-sensitive on *nix.
See the PostgreSQL manual section on identifiers and keywords for details on PostgreSQL's behaviour. You should probably read that anyway, so you understand how string quoting works among other things.
You need to pick one of these options:
Change your code not to quote identifiers;
Change your migration tool to quote identifiers when creating the schema;
Hand migrate the schema instead of using a migration tool;
Fix the quoting of identifers in the tool-generated SQL by hand; or
lower-case all identifiers so it doesn't matter for Pg
The last option won't help you when you add Oracle support and discover that Oracle upper-cases all identifiers, so I'd recommend picking one of the first four options. I didn't find a way to get the migration tool to quote identifiers in a quick 30second Google search, but didn't spend much time on it. I'd look for options to control quoting mode in the migration tool first.
PostgreSQL does not have a configuration option to always treat identifiers as quoted or to use case-insensitive identifier comparisons.
This is far from the only incompatibility you will encounter, so be prepared to change queries and application code. In some cases you might even need one query for MySQL and another for PostgreSQL if you plan to continue to support MySQL.
If you weren't using sql_mode = ANSI and using STRICT mode in MySQL you'll have a lot more trouble with porting than if you were using those options, since both options bring MySQL closer to SQL standard behaviour.