> 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. > the easy way to go. Unfortunately ... our server isn't coming for another > month. My boss wants a prototype. OIC. You're talking about being in the real world, aren't you? (S) 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.... > 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 and 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. > Unfortunately I am the DBA. Noone else to ask for help here. ROFLPMPLOL....that's how I got my job!!!!! (S) > 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..... > 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). 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) DBA's aren't know for being cheap or readily accessable, so you may want to start searching for one now/ASAP. > Thanks a ton, No problem, glad I can help! HTH, Scot.