Unfortunately the change from local .dbf files to a client-server system
using a remote rdb *is* a fairly steep learning curve, but it probably
isn't worth the effort for a stub-end system with no onward development.
You could try this (which omits the intermediate options and their
useful learning opportunities):
VFP Data Explorer is *excellent* at finding SQL Server db's on the same
network - use it to find one (or a couple of related) files that have
already been 'converted'; drop it on a cursor adapter and have a play
(VFP Help! is your friend). Have a play, then see if you can get it to
work with the data environment of a copy of your form with the grid.
hth
On 22/06/2015 14:22, Kurt Wendt wrote:
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/[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.
