home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6419 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.0 KB
  1. Xref: sparky comp.databases:6419 comp.databases.theory:425 comp.databases.oracle:1423
  2. Path: sparky!uunet!bonnie.concordia.ca!IRO.UMontreal.CA!kovic.IRO.UMontreal.CA.IRO.UMontreal.CA!jalbert
  3. From: jalbert@IRO.UMontreal.CA (Francois Jalbert)
  4. Newsgroups: comp.databases,comp.databases.theory,comp.databases.oracle
  5. Subject: Objects and Oracle?
  6. Message-ID: <1992Aug28.214443.24903@IRO.UMontreal.CA>
  7. Date: 28 Aug 92 21:44:43 GMT
  8. Sender: news@IRO.UMontreal.CA
  9. Reply-To: jalbert@IRO.UMontreal.CA (Francois Jalbert)
  10. Organization: Universite de Montreal
  11. Lines: 46
  12.  
  13. Greetings all!
  14.  
  15. Our company develops software to run under Windows using the toolbook package 
  16. in the early development phases. We do everything using objects and fairly 
  17. complex inheritance schemes. Our current task is to develop some software to 
  18. act as a front end to some relational database system. We are currently trying 
  19. to figure out if Oracle might do the job for us. We phoned the local Oracle 
  20. outfit but their answers were very vague, to say the least. I hope that by 
  21. asking to net, somebody out there will know more than our local Oracle folks. 
  22.  
  23. Primarily, the database manager we seek should
  24.  
  25.   - be a true RDBMS
  26.   - manage table creation and updates using SQL commands
  27.   - run under Windows 3.1 on top of DOS 5.0
  28.   - be callable from C (or C++) according to the DB2 standard of embedded SQL
  29.   - support referential integrity, transaction security (commit rollback),
  30.     multiusers, networks, to name the few I can think of at the moment.
  31.  
  32. We discarded DBase since it's not really SQL at the root, and it's too much 
  33. micro oriented. Our customers are more the Oracle, Informix, Ingres types.
  34.  
  35. If Oracle could only have offered us SQL*form, SQL*report, and other "closed" 
  36. means of access, we would immediately have discarded it. But we recently heard 
  37. about Oracle Card and Oracle Access. These last two tools might make Oracle 
  38. open enough for our needs. Let's be clear about this, we want to keep the full 
  39. control of our Windows application running on Novell by doing all the interface 
  40. stuff using Borland C++ and toolbook. The key word I constantly hear in the 
  41. office these days is "open". My understanding is that DB experts programming in 
  42. C are fully aware of what this term implies. (I'm no DB expert) 
  43.  
  44. I understand Oracle Card is related to Windows. Do we need that at all? Is it 
  45. just a fancy Windows remake of old stuff, ie SQL*form and/or SQL*report? In 
  46. which case we would never touch it.
  47.  
  48. Oracle Access seems to be a revamped version of Pro-C. What are the differences 
  49. between the two? Is one better for objects than the other? For Windows?
  50.  
  51. I guess what we need is a way to access the power of SQL and RDBMS from within 
  52. our own Windows applications. If anybody has played with those ideas and has 
  53. something to report, please do so! We are also thinking about some small 
  54. independent products that also boast of full SQL support, but Oracle is a big 
  55. name and might look good on our company's record. We hope it won't prove too 
  56. closed for our need. We are really new to DB stuff.
  57.  
  58. Thank you very much for any advice, Franky
  59.