Thread: Re: [BUGS] bug reporting
Alexandr S wrote: > Pgadmin 3.1 don t work (operations like insert rows) with columns > named in russian language (title of column in russian language). But > the same operations using PhpPgAdmin - all works very well, right. > And if replace russian title of column with equivalent in english - > all works very well. PgAdmin responds the message: "2003-10-03 > 14:15:15 ERROR : Column not found in pgSet: еще_колонка". Operation > System: Windows XP, distribution binary (zip), language russian. > Hi Alexandr, you're on the wrong list, please use pgadmin-support for pgAdmin related questions. Which tool did you use to insert the data? Regards, Andreas
Hi Andreas. I take the report that it looks like this in Japan. It was a problem with Windows. There is patch which I suggested before. It is important though this was ignored. See it again. OT) My server is in bad condition, and I haven't been able to talk well since yesterday. :-( regards, Hiroshi Saito From: "Andreas Pflug" <pgadmin@pse-consulting.de> > Alexandr S wrote: > > > Pgadmin 3.1 don t work (operations like insert rows) with columns > > named in russian language (title of column in russian language). But > > the same operations using PhpPgAdmin - all works very well, right. > > And if replace russian title of column with equivalent in english - > > all works very well. PgAdmin responds the message: "2003-10-03 > > 14:15:15 ERROR : Column not found in pgSet: еще_колонка". Operation > > System: Windows XP, distribution binary (zip), language russian. > > > Hi Alexandr, > > you're on the wrong list, please use pgadmin-support for pgAdmin related > questions. > > Which tool did you use to insert the data? > > Regards, > Andreas
Next bug. --with full russian version of Pgadmin 3.1 (with russian title of column and russian inserted data) : there is problem when selecting, inserting relatively large block of data (for example , excerpt of some text about 100 words size and more). Pgadmin suddenly ends to work and then I have to start pgadmin again, but fortunately data don t loose. And pgadmin don t export any russian data to *.csv or *.dat - pgadmin suddenly ends to work without saving any data. As I understood, there is patch that solve this problems, so I hope new version of pgadmin will appear as soon as possible. --with full english version of Pgadmin : this problems absent , but there is one thing that I don t understand and don t like me. When exporting relatively large block of data (text with, for example, 100 words size) pgadmin saves to *.csv only little part of data in the end of which follows ".." . So pgadmin don t safe full content of row. Is it right behavior? How can I safe full content of a row? --when inserting large block of text , data often aligns along one long line, so its hard to view such data. It would be better if data take the form of sell like , for example, Pgaccess does. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Andreas Pflug wrote: > Alexandr S wrote: > >> Pgadmin 3.1 don t work (operations like insert rows) with columns >> named in russian language (title of column in russian language). But >> the same operations using PhpPgAdmin - all works very well, right. >> And if replace russian title of column with equivalent in english - >> all works very well. PgAdmin responds the message: "2003-10-03 >> 14:15:15 ERROR : Column not found in pgSet: еще_колонка". Operation >> System: Windows XP, distribution binary (zip), language russian. >> > Hi Alexandr, > > you're on the wrong list, please use pgadmin-support for pgAdmin > related questions. > > Which tool did you use to insert the data? > > Regards, > Andreas > > >
Alexandr S wrote: > Next bug. > --with full russian version of Pgadmin 3.1 (with russian title of > column and russian inserted data) : there is problem when selecting, > inserting relatively large block of data (for example , excerpt of > some text about 100 words size and more). Pgadmin suddenly ends to > work and then I have to start pgadmin again, but fortunately data don > t loose. And pgadmin don t export any russian data to *.csv or > *.dat - pgadmin suddenly ends to work without saving any data. As I > understood, there is patch that solve this problems, so I hope new > version of pgadmin will appear as soon as possible. Hi Alexandr, There's no patch pending, how did you try to insert the data? Can you supply samples of data, so we can see what's going wrong? > > --with full english version of Pgadmin : this problems absent , but > there is one thing that I don t understand and don t like me. When > exporting relatively large block of data (text with, for example, 100 > words size) pgadmin saves to *.csv only little part of data in the > end of which follows ".." . So pgadmin don t safe full content of > row. Is it right behavior? How can I safe full content of a row? The column size of the Query Tool is limited, you can change the setting in options. Anyhow, if the data is larger than 511, windows will truncate it. The next version of pgAdmin3 will include a "execute to file", which won't suffer any truncation (until the disk is full :-) > > --when inserting large block of text , data often aligns along one > long line, so its hard to view such data. It would be better if data > take the form of sell like , for example, Pgaccess does. Don't know how you'd like it. Some kind of autowrap? You could split lines: INSERT INTO mytable(foo, bar) VALUES (1, 'this is my line || ' and this too' Regards, Andreas
Hi Alexandr, please do not post only to persons, but at least cc the list to avoid messages being lost. > Hi > -----In console: > CREATE DATABASE mydb WITH ENCODING = 'KOI8'; > CREATE TABLE mytable ( моя_колонка varchar ) WITH OIDS; > Then I open pgadmin, open View Data and insert into mytable text_s > (text_s is attached to this letter) - pgadmin suddenly shut down with > error: "An error has occured: Column not found in pgSet : моя_колонка". This was fixed some time ago in cvs. > Then I have to open pgadmin again. Fortunately data didn t lose. Then > I open Query Tool and type: "SELECT * from mytable;" . Result of > the query is right. Then I try to export data but I cann t do that > because pgadmin suddenly shut down without saving any data. > text_s is attached to this letter. What format is this? I can't display it with any tool correctly. Please use Notepad and Save-As some Unicode format. > ----When will approximately new version with "execute to file" > appear? (in a month , in a year ...) It's already in cvs, binary coming soon. > >>> --when inserting large block of text , data often aligns along one >>> long line, so its hard to view such data. It would be better if data >>> take the form of sell like , for example, Pgaccess does. >> >> >> >> >> Don't know how you'd like it. Some kind of autowrap? You could split >> lines: >> >> INSERT INTO mytable(foo, bar) VALUES (1, 'this is my line || >> ' and this too' >> >> >> Regards, >> Andreas >> > ---Yes, some kind of autowrap. Of course I can mannually split line , > but users here usually do such way: ctrl-c from MS Word and ctrl-v > into pgadmin, so data often align along one long line. ?????? Inserting data from Word ????? pgAdmin3 is no text editing tool, and we won't try to interpret the data. I don't know how you're trying to use pgAdmin3, but it may be out of the scope of this tool (notice the name, it's about ADMINistration, not for extensively editing data). Regards, Andreas
Andreas Pflug wrote: > Then I have to open pgadmin again. Fortunately data didn t lose. Then > I open Query Tool and type: "SELECT * from mytable;" . Result of > the query is right. Then I try to export data but I cann t do that > because pgadmin suddenly shut down without saving any data. > >> text_s is attached to this letter. > > > What format is this? I can't display it with any tool correctly. > Please use Notepad and Save-As some Unicode format. > Hi ----It can be usually opened with Opera or Mozilla Firebird having set before Character Coding to windows-1251. May be fonts don t support russian language. Any way with text_s_unicode in unicode there is the same problem: I can t export such data from Query Window ( Pgadmin 3.1) to file. > > >> >>>> --when inserting large block of text , data often aligns along one >>>> long line, so its hard to view such data. It would be better if >>>> data take the form of sell like , for example, Pgaccess does. >>> >>> >>> >>> >>> >>> Don't know how you'd like it. Some kind of autowrap? You could split >>> lines: >>> >>> INSERT INTO mytable(foo, bar) VALUES (1, 'this is my line || >>> ' and this too' >>> >>> >>> Regards, >>> Andreas >>> >> ---Yes, some kind of autowrap. Of course I can mannually split line >> , but users here usually do such way: ctrl-c from MS Word and ctrl-v >> into pgadmin, so data often align along one long line. > > > ?????? Inserting data from Word ????? > pgAdmin3 is no text editing tool, and we won't try to interpret the > data. I don't know how you're trying to use pgAdmin3, but it may be > out of the scope of this tool (notice the name, it's about > ADMINistration, not for extensively editing data). > ----Why not? Let it be. What another tool should I use to insert data to postgresql? Pgadmin already can be excellently used for such operations. Not editing , but just coping from notepad to Pgadmin. Else I have to create my own program using PHP , etc ... �� !!/-
Alexandr S wrote: > ----It can be usually opened with Opera or Mozilla Firebird having set > before Character Coding to windows-1251. May be fonts don t support > russian language. Any way with text_s_unicode in unicode there is > the same problem: I can t export such data from Query Window ( Pgadmin > 3.1) to file. Alexandr, please send this data as Unicode to me, if you want me to have a look at the problem. I can't set my win32 machine to windows-1251. >> > ----Why not? Let it be. What another tool should I use to insert data > to postgresql? Pgadmin already can be excellently used for such > operations. Not editing , but just coping from notepad to Pgadmin. > Else I have to create my own program using PHP , etc ... Sure you can copy/paste the data, but don't expect it to be formatted in any way. There are intentions to create an additional tool with extended data handling capabilities, but that are just plans so far. Regards, Andreas
Andreas Pflug wrote: > Alexandr S wrote: > >> ----It can be usually opened with Opera or Mozilla Firebird having >> set before Character Coding to windows-1251. May be fonts don t >> support russian language. Any way with text_s_unicode in unicode >> there is the same problem: I can t export such data from Query Window >> ( Pgadmin 3.1) to file. > > > Alexandr, > please send this data as Unicode to me, if you want me to have a look > at the problem. I can't set my win32 machine to windows-1251. > text_s_unicode was attached to last letter (file text_s_unicode.txt). I attach this file to this letter again, so look for Attachments in this letter. �� !!/-
Alexandr S wrote: > Andreas Pflug wrote: > >> Alexandr S wrote: >> >>> ----It can be usually opened with Opera or Mozilla Firebird having >>> set before Character Coding to windows-1251. May be fonts don t >>> support russian language. Any way with text_s_unicode in unicode >>> there is the same problem: I can t export such data from Query >>> Window ( Pgadmin 3.1) to file. >> >> >> >> Alexandr, >> please send this data as Unicode to me, if you want me to have a look >> at the problem. I can't set my win32 machine to windows-1251. >> > text_s_unicode was attached to last letter (file text_s_unicode.txt). > I attach this file to this letter again, so look for Attachments in > this letter. > > > Hi Alexandr, this second file version was readable for me. I created database and table with your script, opened ViewData on the table, copied your text_s from Notepad into the column, and stored it. View Data shows the contents fine, Query Tool does so too with select * from mytable. When exporting from query tool, data is truncated (which is normal), the new "execute to file" will export all. So I can't reproduce this problem. In the next days (when Dave gets the time to do so) we'll have V1.0.2 out, which fixes that "column not found" problem, and should work for you. Execute to file isn't included there, we will have snapshots of the forthcoming V1.1 for that. Regards, Andreas >------------------------------------------------------------------------ > >яю !!/- > >------------------------------------------------------------------------ > > >---------------------------(end of broadcast)--------------------------- >TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > >