Обсуждение: invalid byte sequence for encoding
Hy, i have some trouble with the new postgresql 8.4. we check out the compatibility between postgres 8.1 and 8.4 so we have the following error: invalid byte sequence for encoding "WIN1252": 0x00 can anyone say me a work-around? We have to change the escape chars that are inserted by our parser, right? Is it is possible to simulate the postgresql-8.1 behavoir? (some special encoding e.g.) UPDATE belzeil_frei SET bz_zubez= '*', bz_zubez_rtf= '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' WHERE dbrid=295116 Result : ERROR: invalid byte sequence for encoding "WIN1252": 0x00 In that example i try to insert a "*" with rtf-encoding. i have the same problem with SQL_ASCII Daniel. -- Daniel Schuchardt /Softwareentwicklung/ www.prodat-sql.de <http://www.prodat-sql.de>
On sön, 2009-09-13 at 18:51 +0200, Daniel Schuchardt wrote: > UPDATE belzeil_frei SET bz_zubez= '*', bz_zubez_rtf= > '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 > Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' > WHERE dbrid=295116 > > Result : ERROR: invalid byte sequence for encoding "WIN1252": 0x00 > > In that example i try to insert a "*" with rtf-encoding. > > i have the same problem with SQL_ASCII Maybe you want to use the bytea type instead, because you appear to be storing bytes rather than characters.
> In that example i try to insert a "*" with rtf-encoding. It's not the "*" causing the error, it's the "\0"--which I'm pretty sure is not a valid character for an RTF file either. Do you have an encoder which is just blindly reading through the null terminator of a C string and including it in the encoded string. -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice
Hy Scott, as wrote in my awnser to peter everything is working fine in Postgres81. So its not possible thats our parser. Please look in my awnser for peter. Scott Ribe schrieb: >> In that example i try to insert a "*" with rtf-encoding. > > It's not the "*" causing the error, it's the "\0"--which I'm pretty sure is > not a valid character for an RTF file either. Do you have an encoder which > is just blindly reading through the null terminator of a C string and > including it in the encoded string. >
First:In Postgres81 everything is working fine. Second:string:Not really: thats the orignal string, and its a string: (http://de.wikipedia.org/wiki/Rich_Text_Format) (http://en.wikipedia.org/wiki/Rich_Text_Format) {\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset0 Arial;}} \viewkind4\uc1\pard\lang1031\fs20 * \par } you can save it in a textfile and open it with MS-Word or OpenOffice. without our own parser its looking in that way: UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= '{\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset0 Arial;}} \viewkind4\uc1\pard\lang1031\fs20 * \par } ' WHERE dbrid=204800 (((with our parser: UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' WHERE dbrid=204800 )))) WARNING: nonstandard use of escape in a string literal LINE 1: UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= '{\rtf1\ansi\d... ^ HINT: Use the escape string syntax for escapes, e.g., E'\r\n'. Abfrage war erfolgreich durchgeführt: 1 Zeile, 203 ms Ausführungszeit. Peter Eisentraut schrieb: > On sön, 2009-09-13 at 18:51 +0200, Daniel Schuchardt wrote: >> UPDATE belzeil_frei SET bz_zubez= '*', bz_zubez_rtf= >> '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 >> Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' >> WHERE dbrid=295116 >> >> Result : ERROR: invalid byte sequence for encoding "WIN1252": 0x00 >> >> In that example i try to insert a "*" with rtf-encoding. >> >> i have the same problem with SQL_ASCII > > Maybe you want to use the bytea type instead, because you appear to be > storing bytes rather than characters. > > -- Daniel Schuchardt /Softwareentwicklung/ www.prodat-sql.de
Daniel Schuchardt wrote on 13.09.2009 18:51: > UPDATE belzeil_frei SET bz_zubez= '*', bz_zubez_rtf= > '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 > Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' > WHERE dbrid=295116 > > Result : ERROR: invalid byte sequence for encoding "WIN1252": 0x00 > > In that example i try to insert a "*" with rtf-encoding. > > i have the same problem with SQL_ASCII Sounds to me as if you need to set standard_conforming_strings to true in the postgresql.conf http://www.postgresql.org/docs/8.4/static/runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS Thomas
On sön, 2009-09-13 at 22:21 +0200, Daniel Schuchardt wrote: > First:In Postgres81 everything is working fine. In general, older versions of PostgreSQL treated encoding issues much mroe loosely, which subsequently lead to user errors, bugs, and confusion. Later versions are more strict. Therefore, experience dictates that "$oldversion is working fine" often really means "your application code was abusing definitional gaps and bugs". > (((with our parser: > UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= > '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 > Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' > WHERE dbrid=204800 > )))) At the very least, you should escape the \0 to \\0. And then put E'' around the string. The answer recommended elsewhere to set standard_conforming_strings to true will also work, but might break other code that you have currently running. Read its documentation carefully.
I know you are true with definition's and standards, however, that code works for about 6 years ;o) Well, we will change our parser behavoir. We will check out that standard_conforming_strings parameter too but i see a lot of problems with our backup and restore system (plain text pg_dump's) and other points. All in all will Postgres81 understand this E'' (\\0) escape chars too? Or do we have to make a several version for older Postgres versions? Thanks a lot for your hints, Daniel. Peter Eisentraut schrieb: > On sön, 2009-09-13 at 22:21 +0200, Daniel Schuchardt wrote: >> First:In Postgres81 everything is working fine. > > In general, older versions of PostgreSQL treated encoding issues much > mroe loosely, which subsequently lead to user errors, bugs, and > confusion. Later versions are more strict. Therefore, experience > dictates that "$oldversion is working fine" often really means "your > application code was abusing definitional gaps and bugs". > >> (((with our parser: >> UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= >> '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 >> Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' >> WHERE dbrid=204800 >> )))) > > At the very least, you should escape the \0 to \\0. And then put E'' > around the string. The answer recommended elsewhere to set > standard_conforming_strings to true will also work, but might break > other code that you have currently running. Read its documentation > carefully. > > -- Daniel Schuchardt /Softwareentwicklung/ /http://www.prodat-sql.de/
Hi Thomas, thanks a lot we will check out that parameter. But if i understand it in the correct way that parameter will turn off all escape quoting. I have to check out, thanks a lot. Thomas Kellerer schrieb: > Daniel Schuchardt wrote on 13.09.2009 18:51: >> UPDATE belzeil_frei SET bz_zubez= '*', bz_zubez_rtf= >> '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 >> Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\r\n\\par }\r\n\0' >> WHERE dbrid=295116 >> >> Result : ERROR: invalid byte sequence for encoding "WIN1252": 0x00 >> >> In that example i try to insert a "*" with rtf-encoding. >> >> i have the same problem with SQL_ASCII > > > Sounds to me as if you need to set standard_conforming_strings to true > in the postgresql.conf > > http://www.postgresql.org/docs/8.4/static/runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS > > > Thomas > > -- Daniel Schuchardt /Softwareentwicklung/ /http://www.prodat-sql.de/
On Mon, 2009-09-14 at 00:36 +0200, Daniel Schuchardt wrote: > I know you are true with definition's and standards, however, that code > works for about 6 years ;o) > > Well, we will change our parser behavoir. We will check out that > standard_conforming_strings parameter too but i see a lot of problems > with our backup and restore system (plain text pg_dump's) and other points. > > All in all will Postgres81 understand this E'' (\\0) escape chars too? > Or do we have to make a several version for older Postgres versions? What I don't understand about your issue is that '\0' should never have worked in the first place. You can expect it to work in the future, but in old versions this should always have created a problem, either a rejection or perhaps a truncated string. So we're probably not seeing the entire chain of processing here.
> So its not possible thats our parser. And > Second:string:Not really: thats the orignal string, and its a string: Look again. Where is the null character in the original string? Why does your encoded string end with "\0"? In what character set is null a legal character? Your encoder is incorrect. -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice
Yes, you'r correct with the \0 at the end. The problem is that the rtf-object returns wrong terminated string. i can fix the problem with a trim. but look here: XXXXX=# UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 * \r\n\\par }\r\n\0' WHERE ak_nr='TEST'; WARNING: nonstandard use of \\ in a string literal at character 47 HINT: Use the escape string syntax for backslashes, e.g., E'\\'. ERROR: invalid byte sequence for encoding "SQL_ASCII": 0x00 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". XXXX=# SELECT version(); version ------------------------------------------------------------- PostgreSQL 8.4.1, compiled by Visual C++ build 1400, 32-bit ######################################################################### XXXX=# UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\ r\n\\par }\r\n\0' WHERE ak_nr='TEST'; UPDATE 1 XXXX=# SELECT version(); version -------------------------------------------------------------------------------- -------------------------------- PostgreSQL 8.1.11 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (1 row) Scott Ribe schrieb: >> So its not possible thats our parser. > > And > >> Second:string:Not really: thats the orignal string, and its a string: > > Look again. Where is the null character in the original string? Why does > your encoded string end with "\0"? In what character set is null a legal > character? > > Your encoder is incorrect. > -- Daniel Schuchardt /Softwareentwicklung/ /http://www.prodat-sql.de/
Daniel Schuchardt wrote: > but look here: > > XXXXX=# UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= > '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 > Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 * > \r\n\\par }\r\n\0' WHERE ak_nr='TEST'; > WARNING: nonstandard use of \\ in a string literal at character 47 > HINT: Use the escape string syntax for backslashes, e.g., E'\\'. > ERROR: invalid byte sequence for encoding "SQL_ASCII": 0x00 > HINT: This error can also happen if the byte sequence does not match > the encoding expected by the server, which is controlled by > "client_encoding". > XXXX=# SELECT version(); > version > ------------------------------------------------------------- > PostgreSQL 8.4.1, compiled by Visual C++ build 1400, 32-bit > > ############################################################## > > XXXX=# UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf= > '{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0 > Arial;}}\r\n\\viewkind4\\uc1\\pard\\lang1031\\fs20 *\ > r\n\\par }\r\n\0' WHERE ak_nr='TEST'; > UPDATE 1 > XXXX=# SELECT version(); > version > -------------------------------------------------------------- > PostgreSQL 8.1.11 on i486-pc-linux-gnu, compiled by GCC cc > (GCC) 4.1.2 > 20061115 > (prerelease) (Debian 4.1.1-21) > (1 row) PostgreSQL's encoding checks have become more airtight over the versions, so it is no surprise that buggy behaviour in 8.1 has changed by 8.4. The zero character at the end of your string has been wrong all along, only the old version does not complain. You probably never noticed the string truncation because the zero character is the last one. You'll need to fix your program so that it does not emit trailing zero characters. Yours, Laurenz Albe
Greetings!
I have found references on the Internet to a connection string designer for npgsql, but I haven't found where to get it. I don't seem to have it with my download of npgsq. Or am I just looking in the wrong place?
For example, http://npgsql.projects.postgresql.org/exampleprograms.html , which is from the main npgsql web site, contains the following:
I have found references on the Internet to a connection string designer for npgsql, but I haven't found where to get it. I don't seem to have it with my download of npgsq. Or am I just looking in the wrong place?
For example, http://npgsql.projects.postgresql.org/exampleprograms.html , which is from the main npgsql web site, contains the following:
public void ConnectToData()
{
string DSN;
Npgsql.Design.ConnectionStringEditorForm Ndesign = new Npgsql.Design.ConnectionStringEditorForm();
Ndesign.ShowDialog();
DSN = Ndesign.ConnectionString.ToString();
if (DSN == "")
return;
conn = new NpgsqlConnection(DSN);
dset = new DataSet("npdata");
NpAdapter = new NpgsqlDataAdapter();
NpAdapter.SelectCommand = new NpgsqlCommand(query, conn);
NpAdapter.Fill(dset, "npdata");
dtsource = dset.Tables["npdata"];
deleteCmd();
updateCmd();
insertCmd();
}
How can I get ConnectionStringEditorForm?
RobR
Hi! This code is for initial design time support on VS.net 2003. We are still working to get vs.net 2005 design time support as the code to support it changed completely. Sorry for this confusion. I'll check the docs to clarify this. On Tue, Feb 23, 2010 at 17:00, Radcon Entec <radconentec@yahoo.com> wrote: > Greetings! > > I have found references on the Internet to a connection string designer for > npgsql, but I haven't found where to get it. I don't seem to have it with > my download of npgsq. Or am I just looking in the wrong place? > > For example, http://npgsql.projects.postgresql.org/exampleprograms.html , > which is from the main npgsql web site, contains the following: > > public void ConnectToData() > { > string DSN; > Npgsql.Design.ConnectionStringEditorForm Ndesign = new > Npgsql.Design.ConnectionStringEditorForm(); > Ndesign.ShowDialog(); > DSN = Ndesign.ConnectionString.ToString(); > if (DSN == "") > return; > > conn = new NpgsqlConnection(DSN); > dset = new DataSet("npdata"); > NpAdapter = new NpgsqlDataAdapter(); > NpAdapter.SelectCommand = new NpgsqlCommand(query, conn); > NpAdapter.Fill(dset, "npdata"); > dtsource = dset.Tables["npdata"]; > > deleteCmd(); > updateCmd(); > insertCmd(); > } > > How can I get ConnectionStringEditorForm? > > RobR > > > -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://www.npgsql.org http://fxjr.blogspot.com http://twitter.com/franciscojunior Sent from Brasilia, DF, Brazil