> >
> > I haven't tested the latest version of the upsizing wizard - I gave up on the wizards very early on. I am with Borislav on this though. When you move to a SQL backend, you are doing a fairly major revision. That is the perfect time to take a look at the way you want it to work on SQL and make the desired changes. When I moved my database up to SQL, I did the entire design again on paper. I made design decisions that were different than the ones that I would have made in a VFP backend. I then wrote a quick and dirty little "Mickey Mouse" program that imported the data from VFP to SQL. During testing, I actually ran that little Mickey Mouse program nightly. My users would then start out each moring with the same data on both the VFP version and the SQL version. It allowed them to run "real life" tests.
> >
> Ken,
>
> I too would have done it the normal way. But there are lot of problems.
>
> 1) The database isnt mine. I didnt design it nor do i know what is in it
> 2) I have very little time to spare. May be a couple of hours or so in a Week
> 3) There are lot of tables maybe over 100
> 4) Data is sensitive (finincial)
> 5) The tables are free tables
> 6) The tables as i know of is designed very very poorly
> 7) I dont plan to charge anything
>
> My plan
>
> empty the data after making a Copy.
> Create a database and use upsize wizard
> From profiler trace get the data posted to SQL server
> Modify it for my needs (ofcourse the artitect of teh program will be there to help me knowing what is what)
>
> Delete the already created database
> Recreate the database as fresh from the generated modified script
> Create indexes etc ..
>
> Upload the existing data from Foxpro to SQl server
>
> Atleast I wont spend time typing all those fields
>
>
> SuhasHegde

Suhas
Doesn't sound like a terrible plan - but then again, you are simply importing problems into the SQL database. Like Borislav says "But believe me you wouldn't want to support that Database after a while."

This might be a situation where, if you aren't given the time to properly design the SQL database structure, you might want to give this project a miss. Last year, I was asked to do a similar sort of thing. A charity asked me to update their old FP 2.X app to VFP. The biggest problem with thier existing app was a lack of normalization. I could have just "done the quick and dirty conversion" but I passed on it. I told them that it would take a fairly extensive re-write to fix their problems and that I couldn't, in all good concience, leave them with a VFP version of the same bunch of problems. They told me "thank you very much" and got someone else to do it. About three months ago, I was talking to thier president and asked "how is it going?" He told me that I was right about doing it properly. Their new app had all the problems of the old app and a bunch of new problems to go with it. Last month, I got a call: "We are ready to do it right - can you come in and talk to us?" I am now in the process of re-writing that app with a properly defined database.

Ken
You shall know the truth - and the truth shall set you free. (John 8:33)