>The UNIX hardware this Service Provider gives us isnt dependable, it's a living nightmare of constant support by my MIS Group, the IS group from the Service Provider, and our telecommunications engineers that manage our networking concerns. We have no UNIX administrator because not only do we use the Service Provider's hardware & software, we also have to let them hold a never-ending maintenance agreement on all their goods... which includes the responsibility for backups. (I only have to backup the data used in the warehouse, after it's left the Service Provider's software)
>
>I was given a choice here as to the platform to be used for this new box, either Oracle, Informix, or Sybase. I'm choosing Oracle because it is such a tough bird. My next choice was to either let this Oracle box function solely as just a repository for the consolidated data, or function as both repository and backend for my the data warehouse. My mentor on this project helped me decide to split my backend off from the Oracle box because of the trouble we've had with this Service Provider in the past. I trust that Oracle by itself could handle the dual responsibility of acting as both repository and backend, but I dont trust the Service Provider and I really dont want to turn this into an primarily Oracle-based operation and migrate myself right out of a job. :)
>
>The Service Provider is only obligating themselves to provide us with an open database that contains the consolidated real-time data from the 7 UNIX boxes. The product (this Oracle Box) only has to set the food on the table so to speak, they wont commit to making sure the food can be served up to meet our needs once it gets on the table. And if the hardware ends up not being as robust as we need and fails in some way, I have complete confidence the Service Provider will point the finger at us for depending on it to serve its original purpose plus our own purpose. I was told my main priority with this project is to make sure "we dont get screwed" with this migration to client-server processing. So if something goes wrong with this Oracle box that is beyond my control but gets blamed on my data warehouse processing, I'm figuring I'd be looking for a new job shortly thereafter.
>
>I already have the extra backend machine (a big NT Server), and I know this machine can handle the current data we use plus my applications because its doing that now with 2.6. So my logic here is why put all my eggs in one basket when I dont have too. Plus, when I told the boss we would need to hire an Oracle DBA to support this one new machine he wasnt happy. I was told to try and plan this move so that we can hopefully get the Oracle box installed, and hire a consultant to initially setup access rights & users and provide a limited amount of follow up services after that. If we make this Oracle box also serve as the backend for the data warehouse, then we have no choice but to hire an in-house DBA in my opinion... which means I *wont* get to hire a database support person to keep menial tasks off of my desk and a staff programmer to help me develop the warehouse apps. Feel free to tell me I work in an unusual environment ;) everybody else does.
>
>So back to my original question... Does Oracle have any built-in Replication features? How hard would it be to get this Oracle box to dump out either all the data to a backend server, or preferably only dump out the data I need for the warehousing tasks? I'm hoping to hear its just a matter of setting up some sort of scheduled task, as opposed to doing something like this with VFP which would require a fair amount of coding. I'm also expecting to find out Oracle will only easily replicate to another Oracle machine which I can live with if I have too, but I would much rather replicate to either local VFP data or SQL Server. Thanks for your patience and input Mark.

Naaah, you wouldn't migrate yourself out of a job. You still have to have someone around to develop the frontend applications to manage the data. To my knowledge, Oracle does not have built-in replication features. I do know you can set up some standard SQL scripts on the server. And I am fairly sure you can somewhat automate this (by using a Unix Daemon) by scheduling them to execute at certain times based on timezones where your customer branches are located.

You could also use VFP to do this very same thing using SQLConnect(), SQLExec() functions and timers. You would be surprised by how little code this takes. I am doing this on the fly for a project I am doing here -- it's easy and very fast. I can use these functions to retrieve data from Oracle into local VFP cursors and/or tables. Getting data from Oracle to SQL Server would probably be a 2-step process -- Oracle to VFP to SQL Server. Someone with SQL Server upsizing knowledge should be able to direct you on moving bulk data from VFP to SQL Server.