home *** CD-ROM | disk | FTP | other *** search
/ 1,000 Best Games for Windows / 1000BestGamesForWindows.iso / _SETUP.1 / PDOXSQL.TXT < prev    next >
Text File  |  1995-02-03  |  15KB  |  371 lines
  1.                     
  2.                     BORLAND SQL LINKS TIPS 
  3.                FOR PARADOX 5.0 FOR WINDOWS USERS
  4.                ---------------------------------
  5.  
  6.  
  7. This file contains important, late-breaking information
  8. you need if your current Paradox 5.0 application uses
  9. the Borland SQL Links and you will be building or using
  10. an application built with a newer version of the SQL
  11. Links. For example, if you are building or using
  12. applications built with Delphi.
  13.  
  14.  
  15. * * * * *
  16.  
  17.  
  18. TABLE OF CONTENTS
  19. -----------------
  20. 1.  General Information
  21. 2.  Informix Driver
  22. 3.  InterBase Driver
  23. 4.  Oracle Driver
  24. 5.  Sybase Driver
  25.  
  26.  
  27.  
  28. 1. GENERAL INFORMATION
  29. ----------------------
  30.  
  31. The Table method sort keyword and sortTo TCursor method are
  32. missing from the list of standard ObjectPAL methods that do 
  33. not support SQL.
  34.  
  35.  
  36.  
  37. 2. INFORMIX DRIVER
  38. ------------------
  39.  
  40. SQLPASSTHRU MODE AND MULTIPLE INFORMIX CONNECTIONS. This 
  41. release of the SQL Link Informix driver uses Informix 
  42. ESQL/C 4.10, which allows only one connection to an 
  43. Informix server at a time from each workstation. This 
  44. means that you cannot be connected to two Informix servers 
  45. or to two databases on the same server simultaneously. 
  46.  
  47. SQL Link operations on Informix databases are of two
  48. types:
  49.  
  50. - those that execute pass-through SQL statements 
  51.   (whether interactively or through ObjectPAL)
  52.  
  53. - all other database operations (such as running queries,
  54.   viewing tables, editing through forms, and executing
  55.   methods of ObjectPAL's tCursor, table, and UIObject
  56.   types)
  57.  
  58. The SQL Link Informix driver "sees" these two types of 
  59. operations as different connections.
  60.  
  61. If you set the Informix driver's SQLPASSTHRU MODE to
  62. one of the SHARED settings (either SHARED AUTOCOMMIT,
  63. which is the default, or SHARED NOAUTOCOMMIT), you 
  64. can execute both pass-through SQL and non-pass-through 
  65. operations in the same connection. If you set 
  66. SQLPASSTHRU MODE to NOT SHARED or blank, you will be 
  67. unable to switch between pass-through SQL statements 
  68. and other non-pass-through operations  in the same 
  69. session. If your first operation on the server is a 
  70. pass-through SQL statement, you can only perform pass-
  71. through SQL operations in that session.  If your first
  72. operation is a non-pass-through operation, you can
  73. only perform non-pass-through operations in that
  74. session.  To switch from one to the other, select the 
  75. alias for the database to which you are connected in 
  76. the Alias Manager dialog, choose Disconnect, then 
  77. choose Connect.
  78.  
  79. If you attempt to perform an operation that cannot be
  80. executed because SQLPASSTHRU MODE is not set to
  81. allow shared connections, you may see the following:
  82.  
  83. -  Pass-through SQL, ObjectPAL, and other operations
  84.    return the error message "Multiple connections
  85.    not supported".
  86.  
  87. -  You can view the SQL equivalent of a QBE query in the 
  88.    SQL Editor, but you cannot execute the pass-through 
  89.    version of that query while QBE is open.
  90.  
  91. If you have set SQLQRYMODE to NOT SHARED and have
  92. already started a session working with QBE, follow these
  93. steps to execute a pass-through query:
  94.  
  95. 1. Use Query | Show SQL to display the SQL equivalent
  96.    of the query in the SQL Editor
  97.  
  98. 2. Use File | Save to save the query as an .SQL file.
  99.  
  100. 3. Use the Alias Manager to explicitly disconnect from
  101.    the Informix server.
  102.  
  103. 4. Use the Alias Manager to explicitly connect to
  104.     the Informix server.
  105.  
  106. 5. Select File | Open | SQL File to select the saved
  107.    SQL query.
  108.  
  109. 6. Execute the query as pass-through SQL.
  110.  
  111.  
  112. To execute a QBE after starting a session in
  113. pass-through:
  114.  
  115. 1. Use the Alias Manager to explicitly disconnect from
  116.    the Informix server.
  117.  
  118. 2. Use the Alias Manager to explicitly connect to
  119.    the Informix server.
  120.  
  121. 3. Select File | Open | Query to open the saved
  122.    Borland desktop query.
  123.  
  124.  
  125.  
  126. WORKING WITH INFORMIX SERIAL FIELDS. The Informix Serial 
  127. field type is a "write once, read always" field type. In
  128. an Informix database, when you insert a new record into a 
  129. table you can either assign a value greater than zero to 
  130. a serial field, or let Informix supply a value for you. If the 
  131. serial field has a unique index placed on it, any value 
  132. assigned to the serial field must be unique. Once the 
  133. record is committed to the table, that value cannot not be
  134. updated.
  135.  
  136. Paradox for Windows supports all of the above behavior of
  137. the Informix Serial type, with the assumption that the
  138. Informix server (and not you) will supply values for any
  139. newly-inserted Serial fields. This means that when you
  140. create a form with a field bound to an Informix serial
  141. field, Paradox "protects" the Serial field by marking it
  142. Read Only.
  143.  
  144. If you want to be able to assign your own value to the
  145. serial field,
  146.  
  147. 1. Put the form in Design Mode.
  148.  
  149. 2. Right Click on the field to display the Property 
  150.    Inspector pop-up menu.
  151.  
  152. 3. De-select Runtime | Read Only.
  153.  
  154. When you run the form, you will be able to specify the 
  155. value to be inserted in the Informix Serial field, along
  156. with other fields in the table.
  157.  
  158. Remember: you cannot insert a duplicate value for the
  159. Serial field if there is a unique index on the field; you
  160. also cannot modify the Serial field of an existing record.
  161.  
  162.  
  163.  
  164. 3. INTERBASE DRIVER
  165. -------------------
  166.  
  167. IMPROVING PERFORMANCE OF ONE-TO-MANY LINKS. Often a one-
  168. to-many link joins a single-field index in the master 
  169. table to the first field of a multi-field index in the 
  170. detail. A common example is ORDERS.ORDERNUM joined to 
  171. LINEITEM.ORDERNUM, where LINEITEM  has a unique index on 
  172. its ORDERNUM and ITEMNUM fields together. In InterBase 3.3 
  173. you can sometimes improve performance by adding a non-
  174. unique index on LINEITEM.ORDERNUM alone.
  175.  
  176.  
  177. BEGINTRANSACTION METHOD. Improvements in the BDE's handling of 
  178. transaction isolation levels may affect your application if it 
  179. uses the OPAL Database method beginTransaction().  (See the 
  180. description of beginTransaction() in the Paradox 5.0 ObjectPAL 
  181. reference or online help for a description of isolation levels.)
  182.  
  183. Unless you use beginTransaction() to initiate a DirtyRead or
  184. ReadCommitted transaction, your application will not be affected by
  185. these improvements.
  186.  
  187. You can use your application unchanged if you set the driver flags
  188. for the InterBase driver.  See READLINK.TXT.  Setting the driver 
  189. flag will make transaction operations compatibile with SQL Links,
  190. version 2.0 (or earlier), disabling the improvements for all 
  191. applications which use the InterBase driver.
  192.  
  193. Under SQL Links, version 2.0 (or earlier), all beginTransaction() 
  194. calls initiated a transaction with the RepeatableRead isolation 
  195. level.  RepeatableRead was used even if the optional isoLevel 
  196. parameter was provided.  Thus all the following beginTransaction() 
  197. calls were equivalent and used RepeatableRead:
  198.  
  199.    var
  200.       db Database
  201.       success Logical
  202.    endVar
  203.    success = db.beginTransaction()
  204.    success = db.beginTransaction("DirtyRead")
  205.    success = db.beginTransaction("ReadCommitted")
  206.    success = db.beginTransaction("RepeatableRead")
  207.  
  208. BDE's new transaction support runs your transaction at a level
  209. supported by the server at or above the level you specify.  If the
  210. server does not support an isolation level at or above that level, an
  211. error will be returned.  If you specify an isolation level and write
  212. your application correctly assuming you have that isolation level,
  213. your application will execute correctly or will receive an error.
  214.  
  215. For InterBase databases, db.beginTransaction() and
  216. db.beginTransaction("RepeatableRead") still initiate a RepeatableRead
  217. transaction.  db.beginTransaction("DirtyRead") and
  218. db.beginTransaction("ReadCommitted") initiate a ReadCommitted
  219. transaction.
  220.  
  221. So, if your application specified DirtyRead or ReadCommitted, it will
  222. now execute at the ReadCommitted level instead of the RepeatableRead
  223. level.  You should test it to ensure that it operates correctly at
  224. the ReadCommitted level.
  225.  
  226.  
  227.  
  228. 4. ORACLE DRIVER
  229. ----------------
  230.  
  231. BEGINTRANSACTION METHOD. Improvements in the Borland Database Engine's 
  232. (BDE) handling of transaction isolation levels will affect your 
  233. application if it uses the OPAL Database method beginTransaction().  
  234. (See the description of beginTransaction() in the Paradox 5.0 
  235. ObjectPAL reference or online help for a description of 
  236. isolation levels.)
  237.  
  238. If you do not use beginTransaction(), your application will not be
  239. affected by these improvements.
  240.  
  241. You can use your application unchanged if you set the driver flags
  242. for the Oracle driver.  See READLINK.TXT.  Setting the driver flag will
  243. make transaction operations compatibile with SQL Links, version 2.0 
  244. (and earlier), disabling the improvements for all applications which use
  245. the Oracle driver.
  246.  
  247. If you do not set the driver flag, you will probably need to change
  248. your use of the beginTransaction() method.
  249.  
  250. Under SQL Links, version 2.0 and earlier, all beginTransaction() calls 
  251. for Oracle databases initiated a transaction with the ReadCommitted 
  252. isolation level.  ReadCommitted was used even if the optional isoLevel
  253. parameter was provided.  Thus all the following beginTransaction()
  254. calls were equivalent and used ReadCommitted:
  255.  
  256.    var
  257.       db Database
  258.       success Logical
  259.    endVar
  260.    success = db.beginTransaction()
  261.    success = db.beginTransaction("DirtyRead")
  262.    success = db.beginTransaction("ReadCommitted")
  263.    success = db.beginTransaction("RepeatableRead")
  264.  
  265. The BDE's new transaction support runs your transaction at a level
  266. supported by the server at or above the level you specify.  If the
  267. server does not support an isolation level at or above that level, an
  268. error will be returned.  If you specify an isolation level and write
  269. your application correctly assuming you have that isolation level,
  270. your application will execute correctly or will receive an error.
  271.  
  272. For Oracle databases, db.beginTransaction("DirtyRead") and
  273. db.beginTransaction("ReadCommitted") still initiate a ReadCommitted
  274. transaction.  db.beginTransaction() and
  275. db.beginTransaction("RepeatableRead") initiate a read-only
  276. RepeatableRead transaction.  If your application makes updates during
  277. the transaction, you should change these calls to specify
  278. ReadCommitted.  Otherwise an error will be generated when you attempt
  279. to commit the update (or unlock an updated record).
  280.  
  281. If you are using Paradox 4.5 and you use beginTransaction() for an
  282. update transaction on an Oracle database, you must set the driver
  283. flag.  The optional isoLevel argument was added to beginTransaction()
  284. in Paradox 5.0.
  285.  
  286. TABLE\INDEX NAME CAPITALIZATION. Under SQL Links, version 2.0 and 
  287. earlier, Oracle table and index names were always forced to 
  288. uppercase. This release of SQL Links supports names in mixed case.
  289. Previously, SQL Links could be used to access the table 
  290. CUSTOMER but not Customer, for example.
  291.  
  292. Existing Paradox Forms, Reports, QBE queries, Scripts and Libraries
  293. may have refered to these using mixed case.  For example, the table
  294. CUSTOMER might be refered to as Customer in a Form.  Since the names
  295. were forced to upper case, this reference was to CUSTOMER.
  296.  
  297. Under this release of SQL Links, the use of a table name in a Form, 
  298. Report, QBE query, Script or Library which does not match the name 
  299. on the server exactly will fail.  So a reference to the CUSTOMER 
  300. table which is spelled Customer will fail.
  301.  
  302. You can use your Paradox and Oracle objects unchanged if you set the
  303. driver flags for the Oracle driver.  See READLINK.TXT.  Setting the
  304. driver flag will make naming conventions compatibile with SQL Links,
  305. version 2.0 and earlier, disabling the improvements for all
  306. applications which use the Oracle driver.
  307.  
  308. If you do not set the driver flag, you may either change your Paradox
  309. references to match the names on the server (which are probably all
  310. upper case), or change the names on the server to match those in your
  311. Paradox objects.
  312.  
  313.  
  314.  
  315. 5. SYBASE DRIVER
  316. ----------------
  317.  
  318. BEGINTRANSACTION METHOD. Improvements in the Borland Database Engine's 
  319. (BDE) handling of transaction isolation levels will affect your 
  320. application if it uses the OPAL Database method beginTransaction().
  321. (See the description of beginTransaction() in the Paradox 5.0 
  322. ObjectPAL reference or online help for a description of 
  323. isolation levels.)
  324.  
  325. If you do not use beginTransaction(), your application will not be
  326. affected by these improvements.
  327.  
  328. You can use your application unchanged if you set the driver flags
  329. for the Sybase driver.  See READLINK.TXT.  Setting the driver flag will
  330. make transaction operations compatibile with SQL Links, version 2.0 
  331. (and earlier), disabling the improvements for all applications which use
  332. the Sybase driver.
  333.  
  334. If you do not set the driver flag, you will probably need to change
  335. your use of the beginTransaction() method.
  336.  
  337. Under SQL Links, version 2.0 and earlier, all beginTransaction() calls 
  338. for Sybase databases initiated a transaction with the ReadCommitted 
  339. isolation level.  ReadCommitted was used even if the optional isoLevel
  340. parameter was provided.  Thus all the following beginTransaction()
  341. calls were equivalent and used ReadCommitted:
  342.  
  343.    var
  344.       db Database
  345.       success Logical
  346.    endVar
  347.    success = db.beginTransaction()
  348.    success = db.beginTransaction("DirtyRead")
  349.    success = db.beginTransaction("ReadCommitted")
  350.    success = db.beginTransaction("RepeatableRead")
  351.  
  352. The BDE's new transaction support runs your transaction at a level
  353. supported by the server at or above the level you specify.  If the
  354. server does not support an isolation level at or above that level, an
  355. error will be returned.  If you specify an isolation level and write
  356. your application correctly assuming you have that isolation level,
  357. your application will execute correctly or will receive an error.
  358.  
  359. For Sybase databases, db.beginTransaction("DirtyRead") and
  360. db.beginTransaction("ReadCommitted") still initiate a ReadCommitted
  361. transaction.  db.beginTransaction() and
  362. db.beginTransaction("RepeatableRead") attempt to initiate a
  363. RepeatableRead transaction, but an error is generated because
  364. RepeatableRead transactions are not supported.  You should change
  365. these calls to specify ReadCommitted.
  366.  
  367. If you are using Paradox 4.5 and you call beginTransaction() for a
  368. Sybase database, you must set the driver flag.  The optional isoLevel
  369. argument was added to beginTransaction() in version 5.0.
  370.  
  371.