Thread: backup/restore buttons deactivated

backup/restore buttons deactivated

From
Christian Sengstock
Date:
Hi,
i have a problem with pgadminIII 1.2.2 (deb build) on debian. I access
a remote postgres database (8.0.3) on linux.

the "Tools->Backup" and "Tools->Restore" functionality is always
deactivated! Doesn't matter where i am in the database tree.

About my system:
* I don't have a local postgres database installed on my machine where
the pgadminIII client is running.
* The "/usr/pgsql/bin" directory on the remote linux machine is not in the path.

could one of these be the reason for my problem? i can't install a
local postgres db on my machine where pgadmin is running, nor can i
change the path on the remote linux machine.

or am i just missing a silly thing!?

thanks,
chris


Re: backup/restore buttons deactivated

From
Andreas Pflug
Date:
Christian Sengstock wrote:
> Hi,
> i have a problem with pgadminIII 1.2.2 (deb build) on debian. I access
> a remote postgres database (8.0.3) on linux.
> 
> the "Tools->Backup" and "Tools->Restore" functionality is always
> deactivated! Doesn't matter where i am in the database tree.
> 
> About my system:
> * I don't have a local postgres database installed on my machine where
> the pgadminIII client is running.
> * The "/usr/pgsql/bin" directory on the remote linux machine is not in the path.
> 
> could one of these be the reason for my problem? 

You need the executables in the path for pgAdmin.

Regards,
Andreas


Re: backup/restore buttons deactivated

From
John DeSoi
Date:
On Nov 18, 2005, at 5:45 AM, Andreas Pflug wrote:

> You need the executables in the path for pgAdmin.


I was wondering about this also for OS X. I got it to work by putting  
pg_dump and pg_restore inside pgAdmin OS X package (MacOS folder). Is  
this what you mean by "in the path" -- same directory as the executable?

I could not find any information about setting this up in the  
documentation.

BTW, the option to set the file location in OS X using the standard  
file dialog is broken (button with 3 dots next to the path). You  
can't specify a path unless you choose an existing file. Basically,  
an "open" file dialog is used rather than one that allows you to  
specify the path.


John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL



Re: backup/restore buttons deactivated

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of John DeSoi
> Sent: 18 November 2005 18:44
> To: Andreas Pflug
> Cc: Christian Sengstock; pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] backup/restore buttons deactivated
>
>
> On Nov 18, 2005, at 5:45 AM, Andreas Pflug wrote:
>
> > You need the executables in the path for pgAdmin.
>
>
> I was wondering about this also for OS X. I got it to work by
> putting
> pg_dump and pg_restore inside pgAdmin OS X package (MacOS
> folder). Is
> this what you mean by "in the path" -- same directory as the
> executable?

No, though pgAdmin will look in it's own directory as well. Under the
hood of OSX, in it's BSD roots you'll find it has an executable search
path like DOS/Windows/Unix. You can check the path with something like
"echo $PATH" from a command prompt. What I don't know offhand, is
whether the path has any effect on things started from the Finder, or if
it does, what shell is everything running under (and therefore, what
script should be modified)?

I will check this out when I'm next on my Mac.

> I could not find any information about setting this up in the
> documentation.
>
> BTW, the option to set the file location in OS X using the standard
> file dialog is broken (button with 3 dots next to the path). You
> can't specify a path unless you choose an existing file. Basically,
> an "open" file dialog is used rather than one that allows you to
> specify the path.

And that.

Regards, Dave.


Re: backup/restore buttons deactivated

From
Dave Page
Date:


On 19/11/05 9:46 pm, "Dave Page" <dpage@vale-housing.co.uk> wrote:

>  
> 
>> -----Original Message-----
>> From: pgadmin-support-owner@postgresql.org
>> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of John DeSoi
>> Sent: 18 November 2005 18:44
>> To: Andreas Pflug
>> Cc: Christian Sengstock; pgadmin-support@postgresql.org
>> Subject: Re: [pgadmin-support] backup/restore buttons deactivated
>> 
>> BTW, the option to set the file location in OS X using the standard
>> file dialog is broken (button with 3 dots next to the path). You
>> can't specify a path unless you choose an existing file. Basically,
>> an "open" file dialog is used rather than one that allows you to
>> specify the path.
> 
> And that.

Fixed in SVN.

Regards, Dave 




Re: backup/restore buttons deactivated

From
John DeSoi
Date:
On Nov 19, 2005, at 4:46 PM, Dave Page wrote:

> What I don't know offhand, is
> whether the path has any effect on things started from the Finder,  
> or if
> it does, what shell is everything running under (and therefore, what
> script should be modified)?
>
> I will check this out when I'm next on my Mac.


No, an application launched from the Dock or Finder won't have the  
user's search path. Here is link which explains it and one possible  
solution.

But hopefully there is a better solution than creating a plist file.

http://www.misplaced.net/fom/X11/36.html

John



John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL



Re: backup/restore buttons deactivated

From
"Dave Page"
Date:

> -----Original Message-----
> From: John DeSoi [mailto:desoi@pgedit.com]
> Sent: 21 November 2005 06:32
> To: Dave Page
> Cc: Andreas Pflug; Christian Sengstock; pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] backup/restore buttons deactivated

[re: pgadmin3.app not being able to find pg_dump/pg_restore]

> On Nov 19, 2005, at 4:46 PM, Dave Page wrote:
>
> > What I don't know offhand, is
> > whether the path has any effect on things started from the Finder,
> > or if
> > it does, what shell is everything running under (and therefore, what
> > script should be modified)?
> >
> > I will check this out when I'm next on my Mac.
>
>
> No, an application launched from the Dock or Finder won't have the
> user's search path. Here is link which explains it and one possible
> solution.
>
> But hopefully there is a better solution than creating a plist file.
>
> http://www.misplaced.net/fom/X11/36.html

Thanks for the link. We do already have a plist file - the only sensible
option I can think of is to add /usr/local/pgsql/bin (and whereever the
dports version installs if it's different) to the path in it and hope
the user installs PostgreSQL there. We can always include a note in the
docs explaining how to adjust it if required.

Unless anyone has a better idea? Florian or Richard perhaps?

Regards, Dave.


Re: backup/restore buttons deactivated

From
"Dave Page"
Date:

> -----Original Message-----
> From: Florian G. Pflug [mailto:fgp@phlo.org]
> Sent: 21 November 2005 19:25
> To: Dave Page
> Cc: John DeSoi; Andreas Pflug; Christian Sengstock;
> pgadmin-support@postgresql.org; openmacnews@gmail.com
> Subject: Re: [pgadmin-support] backup/restore buttons deactivated
>
> Dave Page wrote:
> > Thanks for the link. We do already have a plist file - the
> only sensible
> > option I can think of is to add /usr/local/pgsql/bin (and
> whereever the
> > dports version installs if it's different) to the path in
> it and hope
> > the user installs PostgreSQL there. We can always include a
> note in the
> > docs explaining how to adjust it if required.
> >
> > Unless anyone has a better idea? Florian or Richard perhaps?
> This code in appbase.cpp
> -------------------------
> #if defined(__WXMAC__)
>
>      //When using wxStandardPaths on OSX, wx defaults to the unix,
>      //not to the mac variants. Therefor, we request wxStandardPathsCF
>      //directly.
>      wxStandardPathsCF stdPaths ;
>      dataDir = stdPaths.GetDataDir() ;
>
>      if (wxDir::Exists(dataDir + HELPER_DIR))
>          path.Add(dataDir + HELPER_DIR) ;
>      if (wxDir::Exists(dataDir + SCRIPT_DIR))
>          path.Add(dataDir + SCRIPT_DIR) ;
>
> #else // other *ixes
> --------------------------
>
> adds $bundledir/Contents/SharedSupport/helper to the path used by
> pgadmin3. I think pgadmin3 should copy pg_dump and pg_restore into
> that dir during "make install" - I remember trying to do that a while
> ago, but couldn't find a reliable way to find the pg_dump and
> pg_restore
> while doing "make install". But since pgadmin3 now uses pg_config, I
> guess the path to pg_dump and pg_restore could be queried
> from pg_config.
>
> Another problem is that this won't guarantee that the version
> of pg_dump
> and pg_restore matches the version of the database which pg_dump and
> pg_restore are trying to backup/restore - but that's a more general
> problem - how does it work on windows, btw?

We always build against the absolute latest version of PostgreSQL -
pg_dump is backwards compatible so it should always work. Of course,
it's not beyond he realms of possibility that it might produce a dump
that cannot be re-imported into an old version of PostgreSQL, but if you
run into that situation, about all you can do is either upgrade, or
replace pg_dump with an older version.

> I think that I can find a way to copy pg_dump and pg_restore into the
> bundle (during "make install"), but I'll be very busy the
> next few days,
> so it'll have to wait until the weekend.

OK, great - thanks.

Regards, Dave.


Re: backup/restore buttons deactivated

From
"Florian G. Pflug"
Date:
Dave Page wrote:
> Thanks for the link. We do already have a plist file - the only sensible
> option I can think of is to add /usr/local/pgsql/bin (and whereever the
> dports version installs if it's different) to the path in it and hope
> the user installs PostgreSQL there. We can always include a note in the
> docs explaining how to adjust it if required.
> 
> Unless anyone has a better idea? Florian or Richard perhaps?
This code in appbase.cpp
-------------------------
#if defined(__WXMAC__)
    //When using wxStandardPaths on OSX, wx defaults to the unix,    //not to the mac variants. Therefor, we request
wxStandardPathsCF   //directly.    wxStandardPathsCF stdPaths ;    dataDir = stdPaths.GetDataDir() ;
 
    if (wxDir::Exists(dataDir + HELPER_DIR))        path.Add(dataDir + HELPER_DIR) ;    if (wxDir::Exists(dataDir +
SCRIPT_DIR))       path.Add(dataDir + SCRIPT_DIR) ;
 

#else // other *ixes
--------------------------

adds $bundledir/Contents/SharedSupport/helper to the path used by 
pgadmin3. I think pgadmin3 should copy pg_dump and pg_restore into
that dir during "make install" - I remember trying to do that a while
ago, but couldn't find a reliable way to find the pg_dump and pg_restore
while doing "make install". But since pgadmin3 now uses pg_config, I 
guess the path to pg_dump and pg_restore could be queried from pg_config.

Another problem is that this won't guarantee that the version of pg_dump
and pg_restore matches the version of the database which pg_dump and 
pg_restore are trying to backup/restore - but that's a more general 
problem - how does it work on windows, btw?

I think that I can find a way to copy pg_dump and pg_restore into the 
bundle (during "make install"), but I'll be very busy the next few days, 
so it'll have to wait until the weekend.

greetings, Florian Pflug


Re: backup/restore buttons deactivated

From
John DeSoi
Date:
On Nov 21, 2005, at 4:49 PM, Dave Page wrote:

> We always build against the absolute latest version of PostgreSQL -
> pg_dump is backwards compatible so it should always work. Of course,
> it's not beyond he realms of possibility that it might produce a dump
> that cannot be re-imported into an old version of PostgreSQL, but  
> if you
> run into that situation, about all you can do is either upgrade, or
> replace pg_dump with an older version.

The effort may not be warranted here, but for my applications which  
need PostgreSQL utilities I have 3 options:

1. built-in version included with the distribution (default)
2. whatever is found on the program path
3. the user can specify the PostgreSQL bin path to use


>
>
>> I think that I can find a way to copy pg_dump and pg_restore into the
>> bundle (during "make install"), but I'll be very busy the
>> next few days,
>> so it'll have to wait until the weekend.
>>
>
> OK, great - thanks.

Excellent, I think this is the best option.



John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL



Re: backup/restore buttons deactivated

From
"Florian G. Pflug"
Date:
John DeSoi wrote:
>>> I think that I can find a way to copy pg_dump and pg_restore into the
>>> bundle (during "make install"), but I'll be very busy the
>>> next few days,
>>> so it'll have to wait until the weekend.
>>>
>>
>> OK, great - thanks.
> 
> Excellent, I think this is the best option.

The latest nighty build, available at
http://developer.pgadmin.org/snapshots/osx/pgadmin3-trunk-20051125.tar.bz2
should have pg_dump and pg_restore included. Please test if it works for 
you - I tried dumping a small db, and it worked - didn't test restore 
though.

greetings, Florian Pflug

Re: backup/restore buttons deactivated

From
John DeSoi
Date:
On Nov 24, 2005, at 6:14 PM, Florian G. Pflug wrote:

> The latest nighty build, available at
> http://developer.pgadmin.org/snapshots/osx/pgadmin3- 
> trunk-20051125.tar.bz2
> should have pg_dump and pg_restore included. Please test if it  
> works for you - I tried dumping a small db, and it worked - didn't  
> test restore though.


Both backup and restore seem to be working. And thanks for fixing the  
file dialog on the backup interface.

John



John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL