On Wed, 2017-08-09 at 14:21 +0200, basti wrote:
> Hello,
> i have a webapp convert from ascii to uft8.
>
> Now I get in postgres
>
> ERROR: invalid byte sequence for encoding "UTF8": 0xfc
>
> Now I try to log all queries with log_statement = 'all'.
> All queries are longed expected this one.
Hello,
i have a webapp convert from ascii to uft8.
Now I get in postgres
ERROR: invalid byte sequence for encoding "UTF8": 0xfc
Now I try to log all queries with log_statement = 'all'.
All queries are longed expected this one.
Is there a way to debug this.
Best Regards,
Basti
--
Sent via p
John et al,
On Mon, Jul 31, 2017 at 12:13 AM, Igor Korot wrote:
> John,
>
> On Sun, Jul 30, 2017 at 5:32 PM, Igor Korot wrote:
>> Hi, John,
>>
>> On Sun, Jul 30, 2017 at 4:53 PM, John R Pierce wrote:
>>> On 7/30/2017 1:43 PM, Igor Korot wrote:
>>>
>>> what encodings are default on your system ?
John,
On Sun, Jul 30, 2017 at 5:32 PM, Igor Korot wrote:
> Hi, John,
>
> On Sun, Jul 30, 2017 at 4:53 PM, John R Pierce wrote:
>> On 7/30/2017 1:43 PM, Igor Korot wrote:
>>
>> what encodings are default on your system ?`\l+` in psql should show the
>> encodings.
>>
>> Is this "backslash + pi
Hi, John,
On Sun, Jul 30, 2017 at 4:53 PM, John R Pierce wrote:
> On 7/30/2017 1:43 PM, Igor Korot wrote:
>
> what encodings are default on your system ?`\l+` in psql should show the
> encodings.
>
> Is this "backslash + pipe + plus-sign"?
>
> Trying it gives: "Invalid command".
>
>
> \ + low
On 7/30/2017 1:43 PM, Igor Korot wrote:
what encodings are default on your system ?`\l+` in psql should show the
encodings.
Is this "backslash + pipe + plus-sign"?
Trying it gives: "Invalid command".
\ + lower case L + plus sign, thats the psql metacommand to list all
databases with ext
Hi, John,
On Sun, Jul 30, 2017 at 4:34 PM, John R Pierce wrote:
> On 7/30/2017 1:19 PM, Igor Korot wrote:
>>
>> I am using a database for my project that I created inside SQLite3.
>> This database contains a table called "abc" (it is "abc" +
>> symbol with the code 225 -
>> greek letter "beta or
On 7/30/2017 1:19 PM, Igor Korot wrote:
I am using a database for my project that I created inside SQLite3.
This database contains a table called "abc" (it is "abc" +
symbol with the code 225 -
greek letter "beta or a German symbol for "ss").
in what encoding? in ISO 8859-1, -15, beta aka sha
Hi, ALL,
I am using a database for my project that I created inside SQLite3.
This database contains a table called "abc" (it is "abc" +
symbol with the code 225 -
greek letter "beta or a German symbol for "ss").
All I did was to export that database into the text file and then imported this
file i
On Sat, Nov 19, 2011 at 09:32:12AM -0800, pawel_kukawski wrote:
> Is there any way I can store NULL character (\u) in string ?
>
> Or there is only one option that I have change every text field to bytea.
correct question is: why do you want to store \u in text field?
Best regards,
depe
Hi,
Is there any way I can store NULL character (\u) in string ?
Or there is only one option that I have change every text field to bytea.
Regards,
Paweł
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/invalid-byte-sequence-for-encoding-UTF8-0x00-tp5007173p5007173.
BRUSSER Michael wrote:
>>> Is there a way to find the records with the text field containing
Unicode bytes "0xedbebf"?
>>> Unfortunately this is a very old version 7.3.10
>>
>> This should work on 7.3 (according to the documentation):
>> SELECT id FROM nlsdata WHERE position('\360\235\204\236'::byt
-Original Message-
From: Albe Laurenz [mailto:laurenz.a...@wien.gv.at]
Sent: Thursday, June 16, 2011 5:16 AM
To: BRUSSER Michael; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Invalid byte sequence for encoding "UTF8": 0xedbebf
BRUSSER Michael wrote:
> Is there a wa
BRUSSER Michael wrote:
> Is there a way to find the records with the text field containing
Unicode bytes "0xedbebf"?
>
> Unfortunately this is a very old version 7.3.10
This should work on 7.3 (according to the documentation):
SELECT id FROM nlsdata WHERE position('\360\235\204\236'::bytea IN
val
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Alan Hodgson
Sent: Wednesday, June 15, 2011 5:37 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Invalid byte sequence for encoding "UTF8": 0xedbebf
On June 15, 2011 01:18:27 PM BRUSSER Michael wrote:
> Unless there's no other options I don't want to use sed or break file into
> pieces, if possible,
iconv loads everything into RAM. You can use "split", convert the pieces, and
then recombine, I did that when converting a large database to utf-
This is a follow-up on my previous message
http://archives.postgresql.org/pgsql-general/2011-06/msg00054.php
I think I have now some understanding of what's causing the problem, but I
don't have a good solution, instead more questions.
The release notes for v8.1 at
http://www.postgresql.org/doc
That specific character sequence is a result of Unicode implementations
prior to 6.0 mixing with later implementations. See here:
http://en.wikipedia.org/wiki/Specials_%28Unicode_block%29#Replacement_character
You could replace that sequence with the correct 0xFFFD sequence with `sed`
for exampl
We upgrading some old database (7.3.10 to 8.4.4). This involves running
pg_dump on the old db
and loading the datafile to the new db. If this matters we do not use
pg_restore, the dump file is just sourced with psql,
and this is where I ran into problem:
psql: .../postgresql_archive.src/...
2011/5/12 Craig Ringer :
> On 05/11/2011 03:16 PM, AI Rumman wrote:
>>
>> I am trying to migrate a database from Postgresql 8.2 to Postgresql 8.3
>> and getting the following error:
>>
>> pg_restore: [archiver (db)] Error from TOC entry 2764; 0 29708702 TABLE
>> DATA originaldata postgres
>> pg_res
On 05/11/2011 03:16 PM, AI Rumman wrote:
I am trying to migrate a database from Postgresql 8.2 to Postgresql 8.3
and getting the following error:
pg_restore: [archiver (db)] Error from TOC entry 2764; 0 29708702 TABLE
DATA originaldata postgres
pg_restore: [archiver (db)] COPY failed: ERROR: in
I am trying to migrate a database from Postgresql 8.2 to Postgresql 8.3 and
getting the following error:
pg_restore: [archiver (db)] Error from TOC entry 2764; 0 29708702 TABLE DATA
originaldata postgres
pg_restore: [archiver (db)] COPY failed: ERROR: invalid byte sequence for
encoding "UTF8": 0x
Daniel Schuchardt wrote:
> but look here:
>
> X=# 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 strin
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:
X=# UPDATE art SET ak_auftxt= '*', ak_auftxt_rtf=
'{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil\\fcharset0
Arial;}}\r\n\\viewkind4
> 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 incorr
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
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= '*
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) a
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
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
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\lang
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"--whi
> 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 th
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 b
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 par
"Grand, Mark D." writes:
> It turns out that my problem was that the editor I was using (emacs)
> does not properly support utf8 encoding.
Emacs does support utf8 properly.
http://www.emacswiki.org/emacs/ChangingEncodings
It could be I'm biased because I use emacs from CVS, which is going to
] invalid byte sequence for encoding "UTF8": 0xab
Mark D. Grand wrote:
> I am having a vexing problem with a script I am writing to
> populate reference tables in a new database.
>
> I am running postgreSQL 8.3 with psql 8.3.7.
>
> Psql reads this SQL st
Mark D. Grand wrote:
> I am having a vexing problem with a script I am writing to
> populate reference tables in a new database.
>
> I am running postgreSQL 8.3 with psql 8.3.7.
>
> Psql reads this SQL statement:
>
> INSERT INTO META_AUTH.DOMAIN_META_ASSERTION (TITLE, DESCRIPTION,
> META_
On Fri, Jun 5, 2009 at 9:57 AM, Tom Lane wrote:
> The ASCII code for '<' is 0x3c, not 0xab. I am not sure what you are
> actually typing; although it's suggestive that the LATIN1 code 0xab
> corresponds to a symbol that looks approximately like '<<'. The most
> likely bet is that you are typing t
"Grand, Mark D." writes:
> ... I get this message:
> ERROR: invalid byte sequence for encoding "UTF8": 0xab
> 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".
> It is complaining about the '<'
I am having a vexing problem with a script I am writing to populate reference
tables in a new database.
I am running postgreSQL 8.3 with psql 8.3.7.
Psql reads this SQL statement:
INSERT INTO META_AUTH.DOMAIN_META_ASSERTION (TITLE, DESCRIPTION,
META_ASSERTION)
VALUES ('Super-User Aut
On Jul 24, 8:06 pm, [EMAIL PROTECTED] (AlannY) wrote:
> Hi there.
>
> Many times, I'm confronting with that strange problem: invalid byte
> sequence for encoding "UNICODE". So, I guess, Postgresql can't allow me
> to use some symbols which is not a part of UNICODE. But what is that
> symbals?
>
> I
AlannY <[EMAIL PROTECTED]> writes:
> Many times, I'm confronting with that strange problem: invalid byte
> sequence for encoding "UNICODE". So, I guess, Postgresql can't allow me
> to use some symbols which is not a part of UNICODE. But what is that
> symbals?
Doesn't it tell you? AFAICS every
Hi there.
Many times, I'm confronting with that strange problem: invalid byte
sequence for encoding "UNICODE". So, I guess, Postgresql can't allow me
to use some symbols which is not a part of UNICODE. But what is that
symbals?
I'm attaching a screenshot with THAT dead-symbol. As you can see
Glyn Astill wrote:
> I've setup a postgres 8.2 server and have a database setup with UTF8
> encoding. I intend to read some of our legacy data into the table,
> this legacy data is in ASCII format, and as far as I know is 8 bit
> ASCII.
>
> We have a migration tool from mertechdata.com to convert
On Fri, Nov 30, 2007 at 09:44:36AM +, Glyn Astill wrote:
> I've setup a postgres 8.2 server and have a database setup with UTF8
> encoding. I intend to read some of our legacy data into the table,
> this legacy data is in ASCII format, and as far as I know is 8 bit
> ASCII.
Your problem is tha
[Generally it's not a good idea to start a new thread by responding to an
existing one, it confuses people and makes it more likely for your question to
be missed.]
"Glyn Astill" <[EMAIL PROTECTED]> writes:
> Hi People,
>
> I've setup a postgres 8.2 server and have a database setup with UTF8
>
On 11/30/07, Glyn Astill <[EMAIL PROTECTED]> wrote:
>
> Hi People,
>
> I've setup a postgres 8.2 server and have a database setup with UTF8
> encoding. I intend to read some of our legacy data into the table,
> this legacy data is in ASCII format, and as far as I know is 8 bit
> ASCII.
>
> We have
Hi People,
I've setup a postgres 8.2 server and have a database setup with UTF8
encoding. I intend to read some of our legacy data into the table,
this legacy data is in ASCII format, and as far as I know is 8 bit
ASCII.
We have a migration tool from mertechdata.com to convert these files
that ar
- Original Message -
From: "Albe Laurenz" <[EMAIL PROTECTED]>
To: "Ashish Karalkar *EXTERN*" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, September 03, 2007 4:54 PM
Subject: RE: [GENERAL] invalid byte sequence for encoding "UTF8": 0xff
Ashish K
Ashish Karalkar wrote:
>>> I have a data script which runs fine from PgAdmin SQL
>>> Editor,but when I run this from command prompt I get
>>> following error:
>>>
>>> test=# \i /usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql
>>>
>>> psql:/usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql:1
- Original Message -
From: "Ashish Karalkar" <[EMAIL PROTECTED]>
To: "Albe Laurenz" <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2007 4:09 PM
Subject: Re: [GENERAL] invalid byte sequence for encoding "UTF8": 0xff
- Original M
Ashish Karalkar wrote:
> I have a data script which runs fine from PgAdmin SQL
> Editor,but when I run this from command prompt I get
> following error:
>
>
> test=# \i /usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql
>
> psql:/usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql:1:
>
On Mon, Sep 03, 2007 at 01:36:58PM +0530, Ashish Karalkar wrote:
> Hello All,
>
> I have a data script which runs fine from PgAdmin SQL Editor,but when I run
> this from command prompt I get following error:
> test=# \i /usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql
>
> psql:/usr/local/p
Hello All,
I have a data script which runs fine from PgAdmin SQL Editor,but when I run
this from command prompt I get following error:
test=# \i /usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql
psql:/usr/local/pgsql/qsweb1/QSWEB_100_4_Default_Data.sql:1: ERROR: invalid byt
e sequence fo
On Wed, Mar 21, 2007 at 09:54:41AM -0700, Alan Hodgson wrote:
> iconv needs to read the whole file into RAM. What you can do is use the
> UNIX split utility to split the dump file into smaller segments, use iconv
> on each segment, and then cat all the converted segments back together into
> a
On Wednesday 21 March 2007 04:17, "Fuzzygoth" <[EMAIL PROTECTED]>
wrote:
> I've searched the forums and found people with similar problems but
> not much
> on a way to remedy it. I did try using iconv which was suggested in a
> thread
> but it returned an error saying even the 22GB file was too la
Hi,
I am trying currently trying to setup our new database sever, we have
upgraded
to PostgreSQL 8.1.8. When I try to restore the backup (which is stored
as a set
of SQL statements that my restore script feeds into PSQL to execute)
it returns
the following error.
psql:/mnt/tmp/app/application_dat
On 1/16/07, Gary Benade <[EMAIL PROTECTED]> wrote:
I used shp2pgsql.exe to create an import sql for my gis database.
The resultant sql has data like this in it.INSERT INTO "gis"."sa_area"
("label","type","level",the_geom) VALUES
('MÔRELIG','0x2','2','01060001000');
The Ô is ascii char 21
On Tue, Jan 16, 2007 at 03:40:52PM +0200, Gary Benade wrote:
> I used shp2pgsql.exe to create an import sql for my gis database.
> The resultant sql has data like this in it.INSERT INTO "gis"."sa_area"
> ("label","type","level",the_geom) VALUES
> ('MÔRELIG','0x2','2','01060001000');
> The
I used shp2pgsql.exe to create an import sql for my gis database.
The resultant sql has data like this in it.INSERT INTO "gis"."sa_area"
("label","type","level",the_geom) VALUES
('MÔRELIG','0x2','2','01060001000');
The Ô is ascii char 212.
This wont import, PSQL returns
ERROR: invalid byt
Nis Jorgensen wrote:
> Oliver A. Rojo wrote:
>> how do you fix your original db?
>>
>
> Since I had only 3 occurrences of the error, I used
> hand-crafted update statements. The fact that the replacement
> for the invalid characters was constant and plain ascii made
> this very easy.
>
> If you
Markus Wollny wrote:
Nis Jorgensen wrote:
Oliver A. Rojo wrote:
how do you fix your original db?
Since I had only 3 occurrences of the error, I used
hand-crafted update statements. The fact that the replacement
for the invalid characters was constant and plain ascii made
this
Oliver A. Rojo wrote:
Nis Jorgensen wrote:
Oliver A. Rojo wrote:
Hi!
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im
dumping data i got from my old db to my new db but eventually an
error occured
I fixed it by fixing the original db and dumping again. If this is not
desi
Nis Jorgensen wrote:
Oliver A. Rojo wrote:
Hi!
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im
dumping data i got from my old db to my new db but eventually an
error occured
ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
I tried setting the client encoding t
Oliver A. Rojo wrote:
Hi!
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im dumping
data i got from my old db to my new db but eventually an error occured
ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
I tried setting the client encoding to UNICODE but to no avail
Tom Lane wrote:
"Oliver A. Rojo" <[EMAIL PROTECTED]> writes:
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im dumping
data i got from my old db to my new db but eventually an error occured
ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
That's de
"Oliver A. Rojo" <[EMAIL PROTECTED]> writes:
> I've just recently upgraded my database from 7.4.8 to 8.0.1. Im dumping
> data i got from my old db to my new db but eventually an error occured
> ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
That's definitely not valid UNICODE (UTF-
Hi!
I've just recently upgraded my database from 7.4.8 to 8.0.1. Im dumping
data i got from my old db to my new db but eventually an error occured
ERROR: invalid byte sequence for encoding "UNICODE": 0xd141
I tried setting the client encoding to UNICODE but to no avail.
Please help! Thanks!
69 matches
Mail list logo
