Re: Re: DB_Table: Summary and Pre-Call

On Apr 6, 2004, at 11:22 PM, Daniel Convissor wrote:

3. All RDBMS engines store and present date-time info differently, and have different limits on the range of dates and times they can store.

Take a look at http://www.analysisandsolutions.com/code/dates.htm on how to get dates into and out of many DBMS's using the standard SQL-99/ISO format.

This is a great resource; you have mentioned it before and I have gotten good use from it. Hey, everybody, take a look! It's good stuff! But ... ;-) One problem is that the solutions you note on that page require in some cases that the end-user be able to control the database system settings. The target audience for DB_Table may or may not have direct control over the server, which makes it a non-solution for the DB_Table target audience. Another problem as it relates to DB_Table is that a query written for, say, Oracle (using the TO_CHAR function to convert from the native date format to ISO standard) will not work for Microsoft SQL Server (which uses a DATEFORMAT function). Thus, the query itself is not portable, and query portability is one of the primary functions DB_Table aims to provide.

(1) It becomes difficult to tell, from structure alone, that a VARCHAR(19) field is in fact an ISO DATE+TIME field; ...

VARCHAR isn't always the best choice, particularly in cases where one is trying to optimize searches on the table -- fixed with column types are better in most DBMS's.

Have changed these to CHAR -- thanks. -- Paul M. Jones Savant: the simple alternative to Smarty. http://phpsavant.com/