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
---

_______________________________________________
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.

Reply via email to