On Fri, Jun 19, 2015 at 3: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. > > -------------- In VFP what are the rules you follow today? Local cursors that update the true dbf? How do you decide what to update or not update in the local set of records you have today? Do you have a SPROC for an update command? CREATE PROCEDURE [dbo].[EDIErrors_FAckElements_upd] @FAckElementErrorID numeric (18,0), @ErrorDesc varchar (250) as Begin Update [dbo].EDIErrors_FAckElements Set ErrorDesc = @ErrorDesc Where [FAckElementErrorID] = @FAckElementErrorID end This has a single column to update, and you will have to pass in more params and just add , SecondColumn name = @SecondParam until all columns are done. then your statement that you pass in is [exec SprocName ?firstParam, ?secondParam,.... ] It is real easy. This is a single row of VFP values at a time and not an entire dataset. You iterate through the local set to determine what if any rows were updated or added and then chose the correct sproc depenedin on U or A. -- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN 901.246-0159 cell --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ 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/CAJidMYKphmJ=vsjknvmoh1t9mazgxoampsxpwpagyz810kb...@mail.gmail.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.
