Does SQL 2008 Express support the ntext data type? That's a binary datatype and SQL won't try to do any character translation on a binary datatype, iirc. When you save the doc file to a memvar, it contains non-ascii values that you need to preserve. The next problem may be that you probably have single quotes embedded in the binary data which will throw off the parsing of the insert/update statement.
rk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rafael Copquin Sent: Tuesday, June 01, 2010 7:12 PM To: [email protected] Subject: Re: VFP and SQL Server + Word files Thank you, I'm looking forward to it, because I could not make it work. I used a very simple word doc (nothing fancy, just plain text, that is, a simple commercial letter). I did this: public cDoc cDoc = filetostr('c:\wordfiles\myletter.doc') messagebox(cDoc) and I get gibberish. cCmd = [update customers set wordfiles = ]+[']+cDoc+[']+[ where custid=]+Transform(1) SQLExec(nHandle,cCmd) && nHandle obtained previously (the wordfiles field in the SQLServer database is varchar(8000), which is the one that should be used instead of the VFP memofields, in SQLServer Express 2008. I tried with making wordfiles text,varchar(MAX) and varchar(8000) It has been impossible to save this to the SQLServer database. Rafael Copquin El 01/06/2010 11:26, Dave Crozier escribió: > Ricardo& Rafael, > I'm just cleaning up the classes for you at the moment and will let you know > when I post the zip file in Ed's download section. > > Dave C > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Ricardo Aráoz > Sent: 28 May 2010 20:28 > To: ProFox Email List > Subject: Re: VFP and SQL Server + Word files > > Grigore Dolghin wrote: > >> You're right - that's the way it should be done. >> >> >> Now compare this with "Insert Into DestinationTable (Select * From >> SourceTable)". >> > LOL > Yes, you've got a point. > OTOH all your inserts must concern themselves with getting a new ID > versus a slight possibility of having to merge different databases. I > give it to you, it happened, but once in a career is not much by any > standard. > > >> 2010/5/28 Ricardo Aráoz<[email protected]>: >> >>> Grigore Dolghin wrote: >>> >>>> I completely, wholehearted, 100% agree. GUID is the WAY to go - >>>> started using them as PKs back in 2004 I think, when I was asked to >>>> unify the databases of a program created by me and installed initially >>>> in two different locations. 1 year later they came and said "well, >>>> Grig, can you put them together?". Guess what, they were using >>>> integers identity as keys. Well, I was pretty much f*cked up for one >>>> week or so, writing scripts to re-sync those damn integers. Moved to >>>> GUIDs and never looked back. >>>> >>>> >>> I'm certainly not getting it. >>> Go to destination location and add a field named original_pk >>> then append records from origin location putting the origin pk in >>> original_pk (the actual pk will be autoincremented in destination). Then >>> as you append the other tables (the ones that have pk as a foreign key) >>> you check the pk/original_pk as a translation table and correct the >>> reference and that's it. Of course it will get a bit more complicated as >>> you'll have the same problem with mostly every table, but if you think >>> it through a bit and get organized it's not such a big deal. The only >>> concern is to start with the tables that have no foreign references and >>> build it up from there (as there never are circular references in a >>> proper built db). >>> >>> [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] 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/df1eef11e586a64fb54a97f22a8bd04406841ab...@ackbwddqh1.artfact.local ** 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.
