home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8627 < prev    next >
Encoding:
Text File  |  1992-12-22  |  1.8 KB  |  61 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!news.udel.edu!udel!gvls1!jabber!paulr
  3. From: paulr@bts.com (Paul Raulerson)
  4. Subject: Re: FoxPro problem with outer join
  5. Organization: Bux Technical Services -- Doylestown, PA
  6. Date: Mon, 21 Dec 1992 20:11:08 GMT
  7. Message-ID: <1992Dec21.201108.29887@bts.com>
  8. References: <1992Dec21.012636.28374@gopher.dosli.govt.nz>
  9. Lines: 50
  10.  
  11. In article <1992Dec21.012636.28374@gopher.dosli.govt.nz> srlncnc@gopher.dosli.govt.nz (Chris Crook) writes:
  12.  
  13. I am a novice FoxPro programmer, though I can tear up SQL. <grin>
  14. Indeed, if FoxPro supported a full SQL dialect, a SELECT with 
  15. and UPDATE would work just ducky here. But since it doesn't, have your
  16. tried just reading the entire second table into an array, then 
  17. processing the first table using the array? 
  18.  
  19. Something like:
  20.  
  21.   select * from table2 into array myarray;
  22.  
  23. ?
  24. If that is a dumb idea, don't hesitate to tell me. :) 
  25. -Paul
  26.  
  27.  
  28. >
  29. >Can anyone offer any advice on how to solve the following problem in FoxPro
  30. >(other than by using Paradox!).
  31. >
  32. >I have a one table (table1) with the following fields
  33. >
  34. >    unique_key
  35. >    field1
  36. >    field2
  37. >
  38. >and a second table (table2) with the fields
  39. >
  40. >    unique_key
  41. >    field2
  42. >
  43. >The key is common to the two tables, but table2 has only a subset of the
  44. >key values that are present in table1.  I would like to do is replace the
  45. >field2 values in table1 for which there is a corresponding key in table2,
  46. >leaving the rest of table1 untouched.
  47. >
  48. >I cannot do an SQL join because I would lose most of table1 (ie the records
  49. >for which a key does not exist in table2).  I would prefer to avoid using
  50. >a SCAN on table2, because it could be SLOW!
  51. >
  52. >Have you any suggestions - is there anything obvious I have missed in the
  53. >bulky manuals?
  54. >
  55. >Thanks in advance for any suggestions.
  56. >
  57. >
  58. >Chris Crook
  59.  
  60.  
  61.