>> Are you speaking of passing the field values as parameters and
>> just using MS SQL Server stored procedures to add\update
>> the table ... sounds exactly
>
>Yes. You compile an SP in SQL server that does the inserts. You can
>then have SQL handle any RI failures, trigger failures, constraint
>failures, etc. which is not always easy to determine from within
>FoxPro. Furthermore, you then centralize your data rules.
>
I will definitely implement this. If for any reason the update\add
doesn't take ... I can just pass back a error message.

>
>OIC. You're talking about being in the real world, aren't you? (S)

Ain't it a b*tch.

>Another thing you may want to consider is getting your hands on a
>workstation version of SQL Server (even if it is 6.0). This will
>allow you to simulate a SQL server on your desk top. You can do just
>about everything you can with SQL server, only with less connections
>and a few other things you won't care about quite yet.... I think you
>need to be running NT for that though....

I'm giving Microsoft a call about it right now ... ok ... now that
I'm on hold at Microsoft ....

>
>> Thanks ... but for right now ... forms aren't much use to us.
>> We just need
>> to convert our data sources to a database format. Eventually, our field
>> people will need forms once the data is on the server.
>
>Are you changing the data structure, or just porting it? If you are
>basically just importing data, look at the upscale wizard of VFP

I will use the Upscale Wizard to convert our dbc's to SQL Server
but ...

>or the BCP function of SQL Server. MUCH easier, unless you want to
>clean your data first, or only move subsets in, or change the
>structure, etc.

On the initial data which could be as much as 4-5 gig, I expect
to use BCP. After that, on a daily basis, we will be processing
data, parsing data, converting, etc'ing data and will use
(from the sound of what you have written) Remote Views
to pass this processed data to the server.

>
>> I am still researching it, but I plan on building (if possible) the
>> buffering into the Local Views as I will want them on SQL Server. My boss
>> has agreed that no editing will ever be down while the data is being
>> imported early in the morning so I suppose I can use pessistic table
>> buffering. (He gave into something ... a miracle.) [Sure hope I doesn't
>> know about this Web Site.]
>
>I don't think it will really support pessimistic locking. FoxPro may
>act like it does, but SQL Server will not support it in reality.....

I guess I meant to say "optimistic" buffering. I am allowed to
assume noone will change the data on the server until
the morning upload is complete. (Guess I'll be getting to work
pretty early every morning. )

>
>> This just seems too easy and as my boss said, "if it's that easy, your
>> missing something.".
>
>Ya, but it can get harder as you get more advanced (eg).

I don't seem to run into that many problems in VFP/VB because
starting back in dBase II, I've always kept programs basic and
have insisted upon it with my programmers. I must say, my
screens are real cool looking, but they work real good.

Also, if you
>are going to be serious about SQL server (i.e. changing and/or
>maintaining data structures) you will need a DBA (or at least someone
>to do both roles, you perhaps? LOL)

I'll probably act as DBA (notice I said act ... not actually perform <g>).
I tried to impress upon my boss that we will need to retain someone
that actually knows what they are with SQL Server. (At least for
six months or so ... until we get a little experince here).

>DBA's aren't know for being cheap
>or readily accessable, so you may want to start searching for one
>now/ASAP.

And let me guess ... your right down the block from us.

Actually ... we will be installing IIS so remote DBA'ing eventually
could be an option (we'll be lucky to get NT Server\SQL Server
up and running and connected to our existing Lans).

>No problem, glad I can help!

You certainly have. Thanks again.

Gene