Thanks, that really does help in the shift of mind-set. I am struggling right now with the value of using MSDE - even for small apps that right now I would tend to use VFP tables if it weren't for questions of scalability. I am also in the process of blue-skying a couple of verticals and with those there is no doubt we need the option of a SQL SErver backend without having to write two separate applications.

Your approach has helped clarify my thinking a lot, and now I can approach the setup process is a way that will probably yield some results. I'l sure I'll be back with questions as it goes along.


>This is not going to be as easy for you as running the VFP setup wizard and creating an install package.
>
>You've got to first decide if you're going try and tackle the SQL Server (or MSDE) setup or require that your customers already have the server-database installed.
>
>If you can require that they are responsible for the MSDE/SQL Server setup, then you can limit your work to having a routine that connects to the server (Admin privileges required) and then run some statements (SPT) that create the database, tables, stored procs, etc.)
>
>My personal preference is that the customer takes responsibility for the MSDE/SQL Server. If I set it all up for them and they don't know squat about Administering the server, doing backups, etc, then I believe I'm just inviting headaches down the road. Others may disagree.
>
>Anyway, if you don't want to try and automate the setup, another good option may be to generate the SQL scripts that create the database, procs, etc., and let the customer's Administrator run the scripts themselves.
>
>In fact, depending on your customers (and your app), you may very well encounter Administrators that won't let you run your setup on their servers. They may *require* that you provide the scripts for their review. This is not necessarily because they question your competence with SQL Server, but they may have legitimate reasons to change your scripts. For instance, given their specific hardware environment, they may want to split the location of the database, tables, and log files across different disks for performance reasons. Your generic scripts may not fit their environment.
>
>Of course, if your application is small, or your customer base is mostly new to MSDE/SQL Server, then you'll probably have much better odds of a default installation being acceptable across the board.
>
>I may have raised more questions, but just let me know if I can help further.
>
>Guy
>
>
>
>
>>Appalled at the depth of my ignorance on this subject and the massive confusion apparent in my previous question, I delved back into Gary's book on Client Server development to read again and yet again about MSDE and I began to realize the MSDE does not lend itself to simple anything when it comes to distribution. ( The caveats regarding registry keys from previously installed SQL Server etc. alone are enough to make me believe there could be no remote distribution and it is definitely not something I would EVER want to talk any of my users through over the phone )
>>
>>This is indeed a whole new world, and I have to say I don't like it one bit < s >.
>>
>>Anyway, I do realize that the simple-mindedness of the previous question probably does not lend itself to an answer, so my feeling won't be hurt if no one wants to waste time on it < bg >