>When it comes to where to store the data it seems to be more reliably stored in one of the well-respected SQL databases. I see no reason why this should be true but it has been true of every version of dBase and FoxPro that I have ever used.
>
Several things come to mind. Access serialization, the removal of all UI elements from the data engine, not exposing all of data set to changes, recording what is going to be done before doing it, and everything else that is hidden behind the wall from the direct manipulation of the local workstation contribute here. And perhaps the fact that people don't arbitrarily shut off the power to a server before going to lunch.
>The only disadvantage that I can see to using SQL-server, Oracle, DB2, etc. is the cost. Suppose I try to market the reservation app that I have written. Most resorts that would use it would have between 10 to 30 workstations. Say I sell the app for $1000 per workstation most of which is profit. (Not necessarily the way I would market it but close enough for discussion.) If I put the data in a SQL DB my cost goes up by about $250 per workstation, significantly reducing the profit.
>
>How have you dealt with this?
Generally, the client provides the impetus for moving off the native platform; not all, or even the vast majority, of my system deployments use a backend to handle their data, especially when first implemented. If the application is not dependent on non-native-data file handling features for its basic operation, you can and should deploy with the native engine. My belief is that you want to take advantage of the SQL portions of the language in preference to the older procedural constructs; in most cases, it's less work to develop the data services layer this way. Doing this also helps later when you need to move to the backend environment; the same basic techniques and code style is used to manipulate the backend to extract and update data. I don't have to rethink the data services layer stratgey from a process-centric representation to a solution-set-centric representation. The cost of SQL Server may well be less than the cost of really adequate transaction journalling and multi-phase commit implemented by code for a native table.
IOW, backends may be cost-effective because they offer services that you'd otherwise have to write, and would increase the size and complexity of your code needlessly. In some cases, they offer services that can never be fully implemented satisfactorily using native VFP features.
As far as the issue of cost, I make my money for my software; I'm not quoting the cost of the backend, the necessary hardware, the licensing or any of that. I'll let someone else fight over what can be put out to competitive bid. In most cases where there is a compelling need to go to a backend environment, the organization already has a commitment to some central DBMS product, and as long as I can make my software work with their backend, great. I have the tools to deploy and test the SQL Server environment here at home or my office, and I used to have CA-Ingres available to me. If the client wants to deploy on Oracle, they've probably already got a DBA on staff, and site licensing, and the in-house expertise to set up the databases to my specification, and I can go on site and work with them. And get paid for my time.
I don't try to be a complete soup-to-nuts dispenser of their total IT environment. I tend not to know who can provide reasonable levels of service in their local area, and I can't drop everything and run out to Hole-In-The-Wall, Wyoming to troubleshoot a network cable that's been run over one too many times. I'm not in a postion to make sure that they applied the Win98 Y2K patches to all workstations. I can't force them to buy enough CALs to let all their users access their NT Server, and I'm not interested in that environment. Been there, did that, got the tee-shirt. I bitch about lack of vacation time now. At least I can occasionally fit one in to my schedule.
>
>Peter Robinson
