Re: [pgadmin-support] Execute TO in PgadminIII
> -Original Message- > From: Gaetano Mendola [mailto:[EMAIL PROTECTED] > Sent: 21 October 2003 19:45 > To: [EMAIL PROTECTED] > Subject: [pgadmin-support] Execute TO in PgadminIII > > The functionality execute to is not anymore present ? > I currently use this functionality with pgadminII to export > the queries result to Excell. Hi, The functionality is in the development branch, but only execute to file. pgAdmin III has no knowledge of COM so cannot export directly to Excel (would be kinda tricky on Linux/FreeBSD anyway!). Regards, Dave. ---(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
Re: [pgadmin-support] Execute TO in PgadminIII
Hi Dave, Dave Page wrote: -Original Message- From: Gaetano Mendola [mailto:[EMAIL PROTECTED] Sent: 21 October 2003 19:45 To: [EMAIL PROTECTED] Subject: [pgadmin-support] Execute TO in PgadminIII The functionality execute to is not anymore present ? I currently use this functionality with pgadminII to export the queries result to Excell. Hi, The functionality is in the development branch, but only execute to file. pgAdmin III has no knowledge of COM so cannot export directly to Excel (would be kinda tricky on Linux/FreeBSD anyway!). But simple HTML would do the trick for Excel and even OpenOffice can read this: column1column2 ... and so on. Or maybe native OpenOffice, which is XML (in a Zip archive) Schould not be so hard. (This would help maintaining type information) Regards Tino Wildenhain ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] Execute TO in PgadminIII
Dave Page wrote: -Original Message- From: Gaetano Mendola [mailto:[EMAIL PROTECTED] Sent: 21 October 2003 19:45 To: [EMAIL PROTECTED] Subject: [pgadmin-support] Execute TO in PgadminIII The functionality execute to is not anymore present ? I currently use this functionality with pgadminII to export the queries result to Excell. Hi, The functionality is in the development branch, but only execute to file. pgAdmin III has no knowledge of COM so cannot export directly to Excel (would be kinda tricky on Linux/FreeBSD anyway!). Regards, Dave. Ok bu wat about to have a plug-in loadable only on windows for pgAdmin III that permit the export ? Gaetano ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] Execute TO in PgadminIII
> -Original Message- > From: Gaetano Mendola [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 10:38 > To: Dave Page > Cc: [EMAIL PROTECTED] > Subject: Re: [pgadmin-support] Execute TO in PgadminIII > > > Ok bu wat about to have a plug-in loadable only on windows > for pgAdmin III that permit the export ? pgAdmin III doesn't have plugin modules, and even if it did (or we used a #define) would still have a very tough job talking to Excel through COM. The easiest way would be to export to a text file, and load that into Excel. Regards, Dave. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-support] Execute TO in PgadminIII
Dave Page wrote: -Original Message- From: Gaetano Mendola [mailto:[EMAIL PROTECTED] Sent: 22 October 2003 10:38 To: Dave Page Cc: [EMAIL PROTECTED] Subject: Re: [pgadmin-support] Execute TO in PgadminIII Ok bu wat about to have a plug-in loadable only on windows for pgAdmin III that permit the export ? pgAdmin III doesn't have plugin modules, and even if it did (or we used a #define) would still have a very tough job talking to Excel through COM. The easiest way would be to export to a text file, and load that into Excel. I don't like it to have this missing feature passing from pgAdminII to pgAdminIII, one reason for us to not use it. I really don't have time to do it but define a general mechanism for load external libraries and have plug-in could be really great. For example on Linux could be possible export a result set to Gnumeric. Gaetano ---(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
Re: [pgadmin-support] Execute TO in PgadminIII
Hi Dave, Dave Page wrote: -Original Message- From: Gaetano Mendola [mailto:[EMAIL PROTECTED] Sent: 22 October 2003 10:38 To: Dave Page Cc: [EMAIL PROTECTED] Subject: Re: [pgadmin-support] Execute TO in PgadminIII Ok bu wat about to have a plug-in loadable only on windows for pgAdmin III that permit the export ? pgAdmin III doesn't have plugin modules, and even if it did (or we used a #define) would still have a very tough job talking to Excel through COM. The easiest way would be to export to a text file, and load that into Excel. Very sexy would be this: http://www.python.org/doc/current/ext/embedding.html So we would be able to develop a zillon of plugins for every platform - just as a script hook for pgAdmin :-) On Windows one can talk to .com, on Unix do other things. Write small little scripts for tedius tasks... At least its good documented and there is code to borrow from, for example in xchat. Regards Tino Wildenhain ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] German umlauts in pgadmin III
> -Original Message- > From: Andreas Pflug [mailto:[EMAIL PROTECTED] > Sent: 20 October 2003 10:07 > To: Albin Blaschka > Cc: '[EMAIL PROTECTED]'; Reinhard Resch; Wilhelm Graiss > Subject: Re: [pgadmin-support] German umlauts in pgadmin III > > Umlaute are no ascii chars, so they can't converted to unicode. > V1.0.1 which was released some days ago has a workaround for > miscoded databases, leaving encoding conversions to the > client if the db is created SQL_ASCII. I just ran into this on my system with the £ symbol (UK Pound symbol, not #), however the fix doesn't seem to work in CVS tip - Any column that contains a £ value anywhere in it shows up as having a null value. At very least I would expect to see an 'unknown char' symbol in place of the pound sign, and the rest of the string intact. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-support] Execute TO in PgadminIII
> -Original Message- > From: Tino Wildenhain [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 12:31 > To: Dave Page > Cc: Gaetano Mendola; [EMAIL PROTECTED] > Subject: Re: [pgadmin-support] Execute TO in PgadminIII > > Very sexy would be this: > http://www.python.org/doc/current/ext/embedding.html > So we would be able to develop a zillon of plugins for every > platform - just as a script hook for pgAdmin :-) On Windows > one can talk to .com, on Unix do other things. > Write small little scripts for tedius tasks... > > At least its good documented and there is code to borrow > from, for example in xchat. I have been wanting to look at this sort of thing for a while, just never got around to it. I will investigate further when I get more time (big software rollout on Monday). Regards, Dave ---(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
[pgadmin-support] Very slow viewing of large table.
Hello. When in PgAdmin3 I click on a large table, it waits before opening it. As far as I could understand, it issues a row count on a table. Is there way to stop this behaviour? I found a letter about the same problem of February 2002, and Dave Page wrote he was intending to do something about. Am I searching in the wrong place or there is no capability for cancelling count queries? -- Constantin Stefanov ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-support] Very slow viewing of large table.
> -Original Message- > From: Constantin Stefanov [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 14:53 > To: [EMAIL PROTECTED] > Subject: [pgadmin-support] Very slow viewing of large table. > > Hello. > > When in PgAdmin3 I click on a large table, it waits before > opening it. > As far as I could understand, it issues a row count on a > table. Is there way to stop this behaviour? > I found a letter about the same problem of February 2002, and > Dave Page wrote he was intending to do something about. > Am I searching in the wrong place or there is no capability > for cancelling count queries? Under File -> Options -> Query there is an option to control this behaviour, though unless you have a slow server, it should have a sensible value following install. From the helpfile: "Count rows if estimated less than" - In the object browser, if the estimated number of rows in a table (as read from the table statistics) is below this limit, a SELECT count(*) will be performed to find the exact value. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgadmin-support] German umlauts in pgadmin III
> Hello, > > Thanks for all the answers, I solved the problem with "converting" my > databases to Latin1... > (dumping the data, dropping the DB, recreate it with Latin1, reloading > data) > > Was quite an effort, but did it and without problems... > > BTW: PGAdmin III, V1.01 did *not* work in that case (displaying german > umlaute properly...) > > Thanks, > Albin > > -- > > ** Albin Blaschka, Mag. rer. nat. > ** BAL Gumpenstein > ** Projekt: Landschaft und Landwirtschaft im Wandel > ** Tel.: 03682 / 22451 - 244 > ** No trees were killed in the creation of this message. > ** However, many electrons were terrible inconvenienced. > > > > > > > -- > Von: Dave Page[SMTP:[EMAIL PROTECTED] > Gesendet: Mittwoch, 22. Oktober 2003 13:28 > An: Andreas Pflug; Albin Blaschka > Cc: [EMAIL PROTECTED]; Reinhard Resch; Wilhelm Graiss > Betreff: RE: [pgadmin-support] German umlauts in pgadmin III > > > > > -Original Message- > > From: Andreas Pflug [mailto:[EMAIL PROTECTED] > > Sent: 20 October 2003 10:07 > > To: Albin Blaschka > > Cc: '[EMAIL PROTECTED]'; Reinhard Resch; Wilhelm Graiss > > Subject: Re: [pgadmin-support] German umlauts in pgadmin III > > > > Umlaute are no ascii chars, so they can't converted to unicode. > > V1.0.1 which was released some days ago has a workaround for > > miscoded databases, leaving encoding conversions to the > > client if the db is created SQL_ASCII. > > I just ran into this on my system with the £ symbol (UK Pound symbol, not > #), however the fix doesn't seem to work in CVS tip - Any column that > contains a £ value anywhere in it shows up as having a null value. At very > least I would expect to see an 'unknown char' symbol in place of the pound > sign, and the rest of the string intact. > > Regards, Dave. > > ---(end of broadcast)--- TIP 8: explain analyze is your friend
[pgadmin-support] pgAdmin III 1.1.x. Dev snapshot
Ok, I pulled down pgadmin3-20031021-Win32.zip and when I try to use the sort feature in the table view, the "ok" button is not active. I haven't tested the slackware9 snapshot yet so I'll let you is its the same issue- unless someone else can confirm. > Quoting Andreas Pflug <[EMAIL PROTECTED]>: > > > Dave Page wrote: > > > > > > > > > > > > > > > > >>-Original Message- > > >>From: Network Administrator [mailto:[EMAIL PROTECTED] > > >>Sent: 21 October 2003 15:53 > > >>To: Dave Page > > >>Cc: [EMAIL PROTECTED] > > >>Subject: RE: [pgadmin-support] pgAdmin III v1.0.1 Released > > >> > > >>Dave, > > >> > > >>Was that only for the slackware build? I was in > > >>http://snake.pgadmin.org/snapshots/win32/ and I didn't see a > > >>1.1 there. I did put the slackware build though. I haven't > > >>had a chance to use it yet- probably later this week though. > > >> > > >> > > > > > >Yeah, I don't do the win32 snapshots, Andreas does (they're not > > >automated like the Slackware builds). Any chance of a new one please > > >Andreas? > > > > > > > > > > I'm a bit behind because I had such a lot of open stuff on my machine. > > I'll be uploading a new snapshot tonight. > > > > Regards, > > Andreas > > > > > > ---(end of broadcast)--- > > TIP 7: don't forget to increase your free space map settings > > > > > -- > Keith C. Perry > Director of Networks & Applications > VCSN, Inc. > http://vcsn.com > > > This email account is being host by: > VCSN, Inc : http://vcsn.com > > ---(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 > -- Keith C. Perry Director of Networks & Applications VCSN, Inc. http://vcsn.com This email account is being host by: VCSN, Inc : http://vcsn.com ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgadmin-support] pgAdmin III 1.1.x. Dev snapshot
> -Original Message- > From: Network Administrator [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 16:41 > To: Network Administrator > Cc: Andreas Pflug; Dave Page; [EMAIL PROTECTED] > Subject: pgAdmin III 1.1.x. Dev snapshot > > Ok, I pulled down pgadmin3-20031021-Win32.zip and when I try > to use the sort feature in the table view, the "ok" button is > not active. I haven't tested the > slackware9 snapshot yet so I'll let you is its the same > issue- unless someone else can confirm. Yeah, I just fixed that in CVS 'cos I caught me out. It'll be in the next snapshot. Basically it's not recognising a blank filter string as valid or invalid. The quick and dirty fix is to enter a filter string of 1=1 To fool it. Sorry 'bout that. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[pgadmin-support] pgAdmin III error when connecting to server
I have users on database that have spaces in them, pgAdmin 2 worked fine with these but pgAdmin 3 (even with latest snapshot) errors on connect with "missing "=" after "" in connection info string, where the username is " ". Is this a known issue? Yours Unwhettedly, Robert John Shepherd. Editor DVD REVIEWER The UK's BIGGEST Online DVD Magazine http://www.dvd.reviewer.co.uk For a copy of my Public PGP key, email: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-support] pgAdmin III error when connecting to server
> -Original Message- > From: Robert John Shepherd [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 19:15 > To: [EMAIL PROTECTED] > Subject: [pgadmin-support] pgAdmin III error when connecting to server > > I have users on database that have spaces in them, pgAdmin 2 > worked fine with these but pgAdmin 3 (even with latest > snapshot) errors on connect with "missing "=" after "" in > connection info string, where the username is " ". > > Is this a known issue? Hi, It is now :-) I've fixed this in CVS, along with similar possible problems that might have been caused by spaces in usernames & passwords etc. The change will be in the next snapshots. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-support] Very slow viewing of large table.
Dave Page wrote: -Original Message- From: Constantin Stefanov [mailto:[EMAIL PROTECTED] Sent: 22 October 2003 14:53 To: [EMAIL PROTECTED] Subject: [pgadmin-support] Very slow viewing of large table. When in PgAdmin3 I click on a large table, it waits before opening it. As far as I could understand, it issues a row count on a table. Is there way to stop this behaviour? I found a letter about the same problem of February 2002, and Dave Page wrote he was intending to do something about. Am I searching in the wrong place or there is no capability for cancelling count queries? Under File -> Options -> Query there is an option to control this behaviour, though unless you have a slow server, it should have a sensible value following install. From the helpfile: "Count rows if estimated less than" - In the object browser, if the estimated number of rows in a table (as read from the table statistics) is below this limit, a SELECT count(*) will be performed to find the exact value. Thanks, I set that value to 0, and now I have the desired behaviour. But, for that table the values are: Rows(estimated) - 7 Rows(counted) - 77204608 I think the difference is too large. From the debug output I could not understand the query which pg_admin issues to have the value for estimated number of rows. Could you show me that query so I could give it directly from psql to see whether there is an error in my database stats or there is a bug in pg_admin when interpreting query result? -- Constantin Stefanov ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
