>>>>Believe it or not, we still use a VFP app for creating our SQL database. Back in very early 2002, we started a very small startup company (we were bought by a big corporation 2 years later). Initially there were only two programmers and we were learning and developing in C#, but we came from a VFP background and already knew how to connect to and manipulate SQL Server through VFP, so I wrote our little DBA app in VFP (SQL schema changes and lists of StoredProc filenames are stored in VFP tables distributed to the customers). Almost 6 years later, we're still using that little VFP app ... mostly because nobody has the time to convert it to a .NET app!! <g>

Why wouldn't I believe this! VFP works just fine except for Microsoft (and Sedna from what I've been reading (whatever it is)). I am now reconsidering my approach due to the SQL language issue. Ultimately I can't dictate which SQL vendor the clients will select (no pun intended). My goal was to make it seemless for the techs in the company. I just printed the VFP DB class I wrote 11 years ago to determine what functionality I need for data access, perhaps I can come up with a different approach. Question: you distribute this VFP application to create the databases or do you distribute your application with the database file?

>>>>>>We've obviously planned for our applications to be able to use different back-ends (re: the code snippets in my previous post), but how we would accomplish that with Oracle right now I have no idea. We'd need another little DBA app I think (or modify it slightly to be able to connect to Oracle too).

So you only interface with Microsoft SQL - any clients needing Oracle? Wow, so this must be a huge job to convert?