Generically speaking, it will add a burden to support both types of backends. But your market will dictate whether or not that's necessary. The degree of difficulty depends on how you're architected now (frameworks, coding strategies, etc???).

And sure, you can manipulate table updates etc from code (both VFP data and SQL Server data).

If you're somewhat new to SQL Server, my advice would be to migrate some data over to SQL Server and begin playing around with VFP using data from your app and get some familiarity with SQL Server.

Forums here and elsewhere can be a great help as you experiment, think and learn and need answeres to your questions.

Guy






>I am just delving into the possiblity of using SQL server and have some questions on the feasibility.
>
>We have a vertical market applications, and would like to support both a SQL and VFP back-end. I have been informed in the past that it would be a lot easier to abandon the VFP tables altogether, and simply support SQL, instead of supporting both. Generally, how daunting is it to support both? Are there issues that I should be aware of that may make it impossible or entirely impractical?
>
>Also, I am concerned with support. We currently release periodic updates to our clients that contain an empty set of all tables and databases (something of a data-dictionary). This is used to add and update the existing customers tables to match our current srtucture. I would like to similarly update the SQL table configuration from an update. With the security aspects of SQL, I am not sure what problems I may run into. Is it possible to reconfigure SQL tables programatically in this manner? I'm sure it must be, but I haven't found any documentation on this subject.
>
>Thanks,
>
>David