home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6405 < prev    next >
Encoding:
Text File  |  1992-08-29  |  1.5 KB  |  38 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!dcatlas!joet
  3. From: joet@dcatlas.dot.gov (Joe Trott)
  4. Subject: Re: paradox: example elements in an OR expression
  5. Message-ID: <1992Aug28.141511.7234@dcatlas.dot.gov>
  6. Organization: U.S Dept. of Transportation
  7. References: <1992Aug27.042416.11940@access.digex.com>
  8. Distribution: usa
  9. Date: Fri, 28 Aug 1992 14:15:11 GMT
  10. Lines: 26
  11.  
  12. gulati@access.digex.com (Raj K. Gulati) writes:
  13.  
  14. >I recently posted a JOB/CANDIDATE application problem, where the goal
  15. >of the query is to match a job with candidates, where the fields in
  16. >either could be matching, or blank.
  17.  
  18. >This would be easy if it were not for the restriction that paradox
  19. >does not allow example elements to be combined in an OR expression,
  20. >for example:  ~123 or BLANK, which then could be placed in all the
  21. >fields of both ask tables.
  22.  
  23. >Anyone have any ideas on how to either Query, or PAL program around
  24. >this? Help.
  25.  
  26. This may be grisly, but you could try it.  Run two separate queries (or
  27. as many as you need), then after each case append the resulting Answer table to
  28. your results table with Tools|More|Add.  If, for example, you have a results
  29. table for which you design reports and/or forms for use after the matching
  30. process, then your script would first empty it, then run the queries, then
  31. make it available for display/edit/reporting.  You probably _would_ want to
  32. do this; in your Jobs table you could have some fields that describe current
  33. status.  Included in your Matches table, these fields would let you maintain
  34. the status with regard to any particular candidate.
  35.  
  36. -JTT
  37.  
  38.