On Mon, Feb 02, 2004 at 12:11:24PM +0000, Paul Thomas wrote: > > I mean dump == replace. This link might give you some ideas of the issues > involved: > > http://archives.postgresql.org/pgsql-docs/2001-09/msg00013.php Manager folk that are on this list should think about the risks of vendor specific applications. Database and many other applications commonly include vendor specific extensions that tie you to down. Once you are tied to a vendor your list of options gets shorter, expenses go up and your leverage to get something fixed shrinks. ALL software has these issues, open software helps because things are not hidden. Standards are your friend. For the initial poster there is not enough information to respond. There are a couple of components: user interface backend database back end reporting back end backup In some cases the "user interface" part can be scoped and addressed quickly once you know how to access the "backend database". It just depends on the functionality, design and complexity. I have see cases where all the complexity and security was in the client. Granting "back end" access to a perl script quickly was trouble. The "back end backup" may be the easy place to begin. By backing up the primary data to an alternate data base vendor product things like "back end reporting" can be migrated to the mirror. Backend backup, mirroring and reporting efforts can clarify much of the data structure issues and questions. -- T o m M i t c h e l l mitch48-at-sbcglobal-dot-net
