I see, well that was the missing link! Thank you very much Dave Rafael
El 02/06/2010 07:24 a.m., Dave Crozier escribió: > Rafael, > To load any binary document into SQL server you need to convert it first and > the easiest way to do this is wuith the trick being the Cast statement!! > > cFile="c:\temp\temp.doc" > cData=FiletoStr(cFile) > cBlob=Cast(cData as Blob) > > cSQL="Update Customers set WordFiles=?cBlob where ......" > SQLExec(nHandle, cCMD) > > > > Dave C > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Rafael Copquin > Sent: 02 June 2010 00:12 > To: ProFox Email List > 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/[email protected] ** 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.
