Fernando - thanks SO Much for this information. I shall pass it on to my Manager. And, I did already start looking at the 1st link - and it does indeed look helpful.
Regards, Kurt -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Fernando D. Bozzo Sent: Monday, June 22, 2015 10:04 AM To: [email protected] Subject: Re: VFP Migration to MS SQL & a Difficult Screen... Hi Kurt: I do not use SL Server, but I know that there are people already using it in x86 using the 32 bit drivers. The thing, apparently, is you need to install the 32 bit drivers in Wow64 mode, so you can use them. There are some links I found. None of them have a "complete" solution, but I think you can try them (ADO or ODBC should have the same installation way): http://weblogs.asp.net/guybarrette/32-bit-odbc-drivers-on-64-bit-windows http://saltydogllc.com/in-visual-foxpro-using-32-bit-odbc-drivers-on-a-64-bit-machine/ http://www.sqlservercentral.com/Forums/Topic1050209-391-1.aspx http://blogs.msdn.com/b/chaitanya_medikonduri/archive/2008/04/09/how-to-run-32-bit-udl-file-on-a-64-bit-operating-system.aspx Best Regards.- 2015-06-22 15:22 GMT+02:00 Kurt Wendt <[email protected]>: > Ted - I know you wrote that " Visual FoxPro reads and writes SQL > Server (or any other client-server database with ODBC or ADO drivers) just > fine. " > - but I did mention the problem the co. here has w/ADO - since MS > doesn't update it - and it doesn't work on a 64-bit server - from what > I have learned here. That's why we are actually trying to get Away > from the ADO method. I'm not sure if it's the same issue w/ODBC - but, > maybe someone here already knows. > > And, yes - I knew there were several methods to work w/SQL from VFP - > as I knew that MANY Folks here already do it. That's why I posted > here. But, I was also looking for input on the best method with a > learning curve that isn't so steep - since this is supposed to be a > quick project. They want me to implement something ASAP. So - it's > also because of the time crunch - that is why I posted here. > > Since the one project was implemented - move the last few remaining > VFP DBF files to SQL - that project is now on hold from going into > production Until I resolve this New request for this particular > screen. That's why this project is such a time crunch... > > -K- > > -----Original Message----- > From: ProfoxTech [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Friday, June 19, 2015 6:23 PM > To: [email protected] > Subject: Re: VFP Migration to MS SQL & a Difficult Screen... > > Hey Ted! > > True - I wrote that about quitting time - @ least 4 EST - but not true > 4 PST! > > :-) > > Re:ADO - there is a problem - since I heard MS doesn't support it > anymore > - which is stopping where I work from moving 2 a 64-bit server - thus > why ADO is bad - & also why I was looking 4 input. > > But - yes - I know - many folks here use VFP as front-end & SQL 4 > back-end. That's why I posted here. > > Also - others mgrs where I work want an estimate on how long it will > take to fix this screen - so I gotta do something quick & something > w/min learning curve! Also - trying to figure best solution > specifically for a Grid type data access - so I need to kind of pinpoint my > solution... > > FYI - the woman Dev - as I spoke to her today - I printed 2 Ur name as > Editor of book on her desk - so quite a coincidence U should B 1st > response... > > :-) > -K- > > Sent from my iPhone > > > On Jun 19, 2015, at 5:13 PM, Ted Roche <[email protected]> wrote: > > > > Visual FoxPro reads and writes SQL Server (or any other > > client-server database with ODBC or ADO drivers) just fine. You can > > use buffering, remote views, passthrough SQL, cursoradaptors. FoxPro > > makes an awesome front end to a client-server system. > > > > There's way too much to include in an email, especially at quitting > > time. Start with the VFP Help, Use the many FoxPro books your > > employer ought to have (or get them to buy you some!). There's a > > book specifically covering client-server, although it's somewhat > > dated and only covers some of the materials. Once you've got the > > basic terminology down, you can choose the right strategy for you to use. > > > > https://msdn.microsoft.com/en-us/library/aa690493(v=vs.71).aspx > > > > is the first good relevant link "Microsoft Visual FoxPro > > client-server" returned for me. > > > > > >> On Fri, Jun 19, 2015 at 4:36 PM, Kurt Wendt > >> <[email protected]> > wrote: > >> Hello folks, > >> > >> As many of you already know - I started a new job a couple of > >> months > ago. And, although they are working with VFP here - they are migrating > ALL the data files out of VFP into MS SQL. > >> > >> So - one of the systems here - the woman who has been maintaining > >> it > for a while now (although most of that system was initially developed > by > others) - has been given the task to redo that whole system (it's a > relatively small system) - using VB/.net! And, while she is doing the > system re-write, it has become my job to support and update the > Current version of that system. > >> > >> Now - the last major project she did for that system was to Migrate > >> the > few remaining VFP Data files to MS SQL. She finished this a little > while ago - and it's been going thru Testing for a month or so now. > >> > >> One particular screen which allows manipulation of Country Rules - > >> she > rebuilt it based upon .net - and is now connecting to the SQL Table > for it > - instead of the equivalent VFP Table. However, the primary > user/manager of this dept. - has an issue with how the new screen > works. The problem is, the new .net version of the screen won't allow > copy&paste between records like the old screen did. The other issue is > - it's the ONLY screen in this particular system that uses a Grid and > allows Editing of the data in the Grid. In all other cases - editing > is only a Single record at a time - and all other Grids are essentially > read-only. > >> > >> So - during my meeting with my co-worker - she has suggested that > >> we > put the Old VFP screen back - but, just modify it to now work with the > SQL data Table - as opposed to the older VFP Table. > >> > >> AS previously mentioned - this job is my 1st time working with MS SQL. > I've already gotten a fairly good handle on working w/MSSM Studio - > using it to query Tables as well as make updates. And, the systems > here - including this other larger system I have worked on - which has > Most of its Tables in SQL - with only a few left in VFP - have various > routines/Stored Procedures which we use to make data updates to the SQL > Tables. > >> > >> However, for this particular screen I must update. We were > >> discussing > how best to do it. We were even discussing making a Temp version of > the main VFP Table for that screen - but, have it in the users local > folder (its where all temp files go - but, on a network drive). Then - > when they enter into that screen - pull the data down from SQL and > populate that Temp DBF file. Then, after the user is done making the > updates - push the changes back to SQL. Needless to say - the dilemma > - if another user happens to be making changes to that data during a > slightly different process (but using the Same screen) - that would > definitely cause a problem. Also to note. If the user accesses the > screen - but has a particular Dividend record selected - then calling > the screen means that it will ONLY be looking at records for a > Particular Country. But, IF they have No Dividend selected - then the Screen > will be viewing ALL Country records! > >> > >> Obviously - having this screen work w/a Temp version of the Country > Rules data in a VFP DBF file is probably a Bad idea. So - I'm looking > for suggestions on the best way to implement this - especially since I > am now going between VFP and MS SQL. Just so you all know. At one > point - data was going between VFP & SQL via the ADO method. But, in > this small system I am working in - we are using the XML method - > which is how we update data from VFP back into SQL. > >> > >> Thanks in Advance! > >> Kurt Wendt > >> Consultant > >> > >> GLOBETAX > >> 90 Broad Street > >> New York, NY 10004-2205, U.S.A. > >> Tel. +1-212-747-9100 > >> Fax. +1-212-747-0029 > >> Email: [email protected]<mailto:%[email protected]> > >> Web: www.GlobeTax.com<http://www.globetax.com/> > >> > >> GlobeTax does not provide or offer, and this is not, tax, > >> investment or > legal advice. This email and any attachments hereto is intended only > for use by the addressee(s) and may contain confidential information. > If you are not the intended recipient of this e-mail, please > immediately notify the sender at +1-212-747-9100 and permanently > delete the original and any copies of this e-mail. > >> > >> > >> > >> > >> --- StripMime Report -- processed MIME parts --- > >> multipart/alternative text/plain (text body -- kept) text/html > >> --- [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/80838f1ca795b14ea1af48659f35166f1c2...@drexch02.corp.globetax.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.
