Thread: Exporting results from query window to a file displays success when it failed
Hello, Has something changed from 1.4 to 1.6 in how pgadmin exports files? In 1.6 RC1 I have had issues when exporting the results of a query to a file thatA) I get the dialog box that says the Export completed sucessfullyB) Upon opening the file I find it is damagedbecause the results were not completely exported. Maybe on row 66 the end of the line is not present. The file should have had over 100 rows. C) Running it again from the same query window the results noted in A and B occur again but the actual number of rows written to the file are completely different. Usually a fewer amount of rows get exported.D) Copying and pasting the same query into a new querywindow, running the query, and then exporting the data works successfully. I have a co-worker who also had the same problems with the final release of 1.6. I have not tried 1.6.1 but it didn't appear that the changes made between 1.6.1 and 1.6 would have affected this. Client platform is WinXP SP2 and Database platform is Win2003. I cannot reproduce this consistently. Has anyone else seen this? wxWidgets causing grief again? Mike
mike wrote: > Hello, > > Has something changed from 1.4 to 1.6 in how pgadmin exports files? In > 1.6 RC1 I have had issues when exporting the results of a query to a > file that > A) I get the dialog box that says the Export completed sucessfully > B) Upon opening the file I find it is damaged because the results were > not completely exported. Maybe on row 66 the end of the line is not > present. The file should have had over 100 rows. > C) Running it again from the same query window the results noted in A > and B occur again but the actual number of rows written to the file are > completely different. Usually a fewer amount of rows get exported. > D) Copying and pasting the same query into a new query window, running > the query, and then exporting the data works successfully. > > I have a co-worker who also had the same problems with the final release > of 1.6. > > I have not tried 1.6.1 but it didn't appear that the changes made > between 1.6.1 and 1.6 would have affected this. > > Client platform is WinXP SP2 and Database platform is Win2003. > > I cannot reproduce this consistently. There were some changes to check that data was converted to the correct encoding correctly, and to correct a race issue over slow networks where the data export may complete before all the data has actually been retrieved from the server. How are you executing the export - from the file menu on the query tool? What encoding are you using? Is there a small dataset that fails often enough that you could package it as a test case for me to look at? Regards, Dave
We do use File->Export. Encoding I have the radio button set to Local charset. The database is utf-8. Quoting all columns, including column names, quote character ", Column separator is a comma. Row separator is LF I normally export to a network drive. I will get together with my co-worker and see if we can determine which table(s) might be common to the queries. Since it normally works if you cut and paste the same query into a new window, execute and export from the new window I was leaning toward something else other than encoding. Mike On Tue, 05 Dec 2006 11:05:31 +0000, Dave Page wrote > mike wrote: > > Hello, > > > > Has something changed from 1.4 to 1.6 in how pgadmin exports files? In > > 1.6 RC1 I have had issues when exporting the results of a query to a > > file that > > A) I get the dialog box that says the Export completed sucessfully > > B) Upon opening the file I find it is damaged because the results were > > not completely exported. Maybe on row 66 the end of the line is not > > present. The file should have had over 100 rows. > > C) Running it again from the same query window the results noted in A > > and B occur again but the actual number of rows written to the file are > > completely different. Usually a fewer amount of rows get exported. > > D) Copying and pasting the same query into a new query window, running > > the query, and then exporting the data works successfully. > > > > I have a co-worker who also had the same problems with the final release > > of 1.6. > > > > I have not tried 1.6.1 but it didn't appear that the changes made > > between 1.6.1 and 1.6 would have affected this. > > > > Client platform is WinXP SP2 and Database platform is Win2003. > > > > I cannot reproduce this consistently. > > There were some changes to check that data was converted to the correct > encoding correctly, and to correct a race issue over slow networks where > the data export may complete before all the data has actually been > retrieved from the server. > > How are you executing the export - from the file menu on the query tool? > What encoding are you using? > > Is there a small dataset that fails often enough that you could package > it as a test case for me to look at? > > Regards, Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- Open WebMail Project (http://openwebmail.org)
Mike G wrote: > We do use File->Export. > > Encoding I have the radio button set to Local charset. > The database is utf-8. > > Quoting all columns, including column names, quote character ", Column separator is a comma. > > Row separator is LF > > I normally export to a network drive. > > I will get together with my co-worker and see if we can determine which table(s) might > be common to the queries. > > Since it normally works if you cut and paste the same query into a new window, execute > and export from the new window I was leaning toward something else other than encoding. Yeah, I was erring towards the race issue, but that bug was outputting the correct number of rows, just with no data in them (leaving rows and rows of quotes and delimiters) iirc. Might be worth trying the export to a local drive, thoughs that's something of a shot in the dark. Regards, Dave.