Funny you would ask that question at this moment in time. I am working with a client who is (trying) using SQL Server Express 2005 for a data warehouse project (yikes!), and I am using my VFP tables to populate his SQL temp tables used to update his SQL production tables. I created Updateable Remote Views of his tables, and have been successful in importing data into said RVs from my VFP tables, as long as the field names and types match of course. I did try to do a record-by-record SCATTER-APPEND BLANK-GATHER from VFP into SQL, and it worked. I did that to show their one programmer an alternate method of populating his SQL tables as he got edgy about me doing a straight import (don't ask... <g>). Anyway, the SCATTER-APPEND BLANK-GATHER worked fine. I did have the Remote View cursor set to record level buffering, so every time the record pointer moved via APPEND BLANK it would fire an update for the target SQL table. He did end up "allowing" me to do the import process, but I am certain the SCATTER-APPEND BLANK-GATHER for > 1 million records would have worked fine, just taken a tad longer than IMPORT FROM at worst.
BTW, the SQL tables were set up with all field types as c(80), whether my VFP table fields were Numeric, Date, DateTime, Character, or Logical. He wondered why he could not get all the tables populated. SQL Server Express 2005 has a 4Gb max database size limit, and he hit it. So for the past 3 days he has been rebuilding his SQL tables to match my layouts (I had given him those specs previously). I told him how he could use some DISP STRU created layout files for my VFP tables to translate and alter his tables via SQL, but he opted to do it all manually I used that DISP STRU file > code to "convert" my fields through SQL-SELECT output to c(80) for SQL import purposes. What a PITA, but better than manually doing it). Some of my tables have over 220 fields! Uggghhh... But once he gets away from c(80) squared layouts (not VarChar, he used Char!) he ought to be well under 4Gb in his database. If not, he can split the tables between two databases. Better yet, he ought to move to PostgreSQL! I bought him a book on PostgreSQL for Windows the other week as a gift. He put it on a shelf, and I bet it is still there. Shame... Hard to knock it, I know what it is like to be a newbie with database solution creation. At that many in the ProFox group would shudder to see some of my designs (all for good reason, not mainstream). I know back in late 2000 I likely spooked Ed pretty badly when he saw ny core app for the first time! Heh-heh. I made changes based on his recommendations, and it still runs great! But I do not recall doing c(80) squared field designs throughout all tables! I hope my client moves to PostgreSQL. The sooner the better... Gil > -----Original Message----- > From: profoxtech-boun...@leafe.com [mailto:profoxtech- > boun...@leafe.com] On Behalf Of Rafael Copquin > Sent: Wednesday, April 08, 2009 2:54 PM > To: profoxt...@leafe.com > Subject: vfp9 and sqlserver express > > I wonder whether it is possible to send an object from a scatter name > command in VFP to a SQLServer table. > > IOW, in VFP I do this > > select curCustomers > scatter name oCust > > insert into customers from name oCust > > Is it possible to do this but trying to insert into a SQLServer table? > If so, could you post the code? > > Rafael Copquin > > > --- StripMime Report -- processed MIME parts --- > multipart/alternative > text/plain (text body -- kept) > text/html > --- > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/02d201c9b875$fb675f30$f2361d...@rr.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
