ADOdb

Database Abstraction Layer for PHP

User Tools

Site Tools

Trace:
v5:userguide:portable_sql

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
v5:userguide:portable_sql [2016/01/13 16:23] – ↷ Page moved from v5:reference:portable_sql to v5:userguide:portable_sql mnewnhamv5:userguide:portable_sql [2016/03/13 23:52] – [Inserting Records] mnewnham
Line 26: Line 26:
 ^Oracle|select * from (select * from table) where rownum <= 10| ^Oracle|select * from (select * from table) where rownum <= 10|
  
-This feature of getting a subset of data is so useful that in the PHP class library ADOdb, we have a [[v5:reference:selectlimit]] function that allows you to hide the implementation details within a function that will rewrite your SQL for you:+This feature of getting a subset of data is so useful that in the PHP class library ADOdb, we have a [[v5:reference:connection:selectlimit|selectLimit()]] function that allows you to hide the implementation details within a function that will rewrite your SQL for you:
  
 <code php> <code php>
Line 34: Line 34:
 ==== Fetch Modes Within Select Statements ==== ==== Fetch Modes Within Select Statements ====
  
-PHP allows you to retrieve database records as arrays. You can choose to have the arrays indexed by field name or number. However different low-level PHP database drivers are inconsistent in their indexing efforts. ADOdb allows you to determine your prefered mode. You set this by setting the variable [[v5:reference:adodb_fetch_mode]] to either of the constants:+PHP allows you to retrieve database records as arrays. You can choose to have the arrays indexed by field name or number. However different low-level PHP database drivers are inconsistent in their indexing efforts. ADOdb allows you to determine your prefered mode. You set this by setting the variable [[v5:reference:adodb_fetch_mode|$ADODB_FETCH_MODE]] to either of the constants:
   * ADODB_FETCH_NUM (for numeric indexes)   * ADODB_FETCH_NUM (for numeric indexes)
   * ADODB_FETCH_ASSOC (using field names as an associative index).   * ADODB_FETCH_ASSOC (using field names as an associative index).
Line 44: Line 44:
 Another problem with SELECTs is that some databases do not return the number of rows retrieved from a select statement. This is because the highest performance databases will return records to you even before the last record has been found. Another problem with SELECTs is that some databases do not return the number of rows retrieved from a select statement. This is because the highest performance databases will return records to you even before the last record has been found.
  
-In ADOdb, [[v5:reference:recordcount]] returns the number of rows returned, or will emulate it by buffering the rows and returning the count after all rows have been returned. This can be disabled for performance reasons when retrieving large recordsets by setting the global variable [[v5:reference:adodb_countrecs]] = false. This variable is checked every time a query is executed, so you can selectively choose which recordsets to count.+In ADOdb, [[v5:reference:connection:recordcount|recordCount()]] returns the number of rows returned, or will emulate it by buffering the rows and returning the count after all rows have been returned. This can be disabled for performance reasons when retrieving large recordsets by setting the global variable [[v5:reference:adodb_countrecs|$ADODB_COUNTRECS]] = false. This variable is checked every time a query is executed, so you can selectively choose which recordsets to count.
  
-If you prefer to set ''$ADODB_COUNTRECS'' = false, ADOdb still has the [[v5:reference:po_recordcount]] function. This will return the number of rows, or if it is not found, it will return an estimate using ''SELECT COUNT(*)'':+If you prefer to set ''$ADODB_COUNTRECS'' = false, ADOdb still has the [[v5:reference:connection:po_recordcount|po_recordCount()]] function. This will return the number of rows, or if it is not found, it will return an estimate using ''SELECT COUNT(*)'':
  
 <code php> <code php>
Line 98: Line 98:
 ===== Inserting Records ===== ===== Inserting Records =====
  
-When you create records, you need to generate unique id's for each record. There are two common techniques: (1) auto-incrementing columns and (2) sequences.+When you create records, you need to generate unique id's for each record. There are two common techniques:  
 +  * Auto-increment columns 
 +  * Sequences
  
-Auto-incrementing columns are not supported by some databases, so for portability, you have little choice but to use sequences. Sequences are special functions that return a unique incrementing number every time you call it, suitable to be used as database keys. In ADOdb, we use the [[v5:reference:genid]] function. It has takes a parameter, the sequence name. Different tables can have different sequences.+Auto-increment columns are not supported by some databases, so for portability, you have little choice but to use sequences. Sequences are special functions that return a unique incrementing number every time you call it, suitable to be used as database keys. In ADOdb, we use the [[v5:reference:connection:genid|genId()]] function. It has takes a parameter, the sequence name.  
 + 
 +Different tables can have different sequences.
  
 <code php> <code php>
 $id = $connection->GenID('sequence_name'); $id = $connection->GenID('sequence_name');
 $connection->Execute("insert into table (id, firstname, lastname)  $connection->Execute("insert into table (id, firstname, lastname) 
-    values ($id, $firstname, $lastname)");+          values ($id, $firstname, $lastname)");
  
 </code> </code>
-For databases that do not support sequences natively, ADOdb emulates sequences by creating a table for every sequence.+For databases that do not provide native support for sequence, ADOdb provides emulation by creating a table for every sequence.
  
 ===== Binding ===== ===== Binding =====
Line 191: Line 195:
 </code> </code>
  
-For date calculations, we have [[v5:reference:offsetdate]] which allows you to calculate dates such as yesterday and next week in a RDBMS independant fashion. For example, if we want to set a field to 6 hour from now, use:+For date calculations, we have [[v5:reference:connection:offsetdate|offsetDate()]] which allows you to calculate dates such as yesterday and next week in a RDBMS independant fashion. For example, if we want to set a field to 6 hour from now, use:
  
 <code php> <code php>
Line 197: Line 201:
 </code> </code>
  
-The maximum length of a char/varchar field is also database specific. You can only assume that field lengths of up to 250 characters are supported. This is normally impractical for web based forum or content management systems. You will need to be familiar with how databases handle large objects (LOBs). ADOdb implements two functions, [[v5:reference:updateblob]] and [[v5:reference:updateclob]] that allow you to update fields holding Binary Large Objects (eg. pictures) and Character Large Objects (eg. HTML articles):+The maximum length of a char/varchar field is also database specific. You can only assume that field lengths of up to 250 characters are supported. This is normally impractical for web based forum or content management systems. You will need to be familiar with how databases handle large objects (LOBs). ADOdb implements two functions, [[v5:reference:connection:updateblob|updateBlob()]] and [[v5:reference:connection:updateclob|updateClob()]] that allow you to update fields holding Binary Large Objects (eg. pictures) and Character Large Objects (eg. HTML articles):
  
 <code php> <code php>
Line 213: Line 217:
 In general, I avoid using nulls except for dates and default all my numeric and character fields to 0 or the empty string. This maintains consistency with PHP, where empty strings and zero are treated as equivalent, and avoids SQL ambiguities when you use the ANY and EXISTS operators. However if your database has significant amounts of missing or unknown data, using nulls might be a good idea. In general, I avoid using nulls except for dates and default all my numeric and character fields to 0 or the empty string. This maintains consistency with PHP, where empty strings and zero are treated as equivalent, and avoids SQL ambiguities when you use the ANY and EXISTS operators. However if your database has significant amounts of missing or unknown data, using nulls might be a good idea.
  
-ADOdb also supports a portable [[v5:reference:ifnull]] function, so you can define what to display if the field contains a null.+ADOdb also supports a portable [[v5:reference:connection:ifnull|ifNull()]] function, so you can define what to display if the field contains a null.
  
 ===== Stored Procedures ===== ===== Stored Procedures =====
Line 267: Line 271:
 </code> </code>
  
-Note that we quote the $word variable using the  [[v5:reference:qstr]] function. This is because each database quotes strings using different conventions.+Note that we quote the $word variable using the  [[v5:reference:connection:qstr|qStr()]] function. This is because each database quotes strings using different conventions.
  
 ===== Final Thoughts ===== ===== Final Thoughts =====
v5/userguide/portable_sql.txt · Last modified: 2020/12/30 21:32 by peterdd