TODO For MonoQuery and Mono.Data.Sql

MonoQuery
- change SQL View to work the following way: 
  if selected, only execute the selecte statement, otherwise, execute everything
- Make this "execute selected sql/execute everything unselected" a preference.  The current way 
  which separates statements by semicolon can be a preference as well.  However, make 
  the "execute selected sql/execute everything unselected an preference" as default
- create a second view in the sql view.  The top pane being a text view that contains the SQL statements
  and the bottom pane containing a data grid (treeview/liststore) or text view for the results
- create a database table import/export assistant

Mono.Data.Sql
- tie to Mono.Data by using the ProviderFactory to create connections, adapters, command builders, parameters, etc...
  Either Mono.Data.Sql can use Mono.Data.ProviderFactory or merge Mono.Data into Mono.Data.Sql so you can have
  one config file.
- remove the references (as in /r:System.Data.OracleClient.dll) from Mono.Data.Sql and MonoQuery
- have the ability to list servers (data sources) and databases (catalogs) for a given database.  
  * oracle can parse a TNSNAMES.ORA file
  * SQL Server can use port 1434 to discover instances at a host.  Once you connect to a server, 
    you can get a list of databases from sysdatabases.
  * MySQL has show databases  
  * others?
- modify Mono.Data.Sql to be on-demand meaning, you can list tables, but don't get the table columns, indexes, etc...  Only
  Get the table columns for a given table when requested.  Same thing with create the CREATE TABLE SQL.
  Loading all the database objects, such as stored procedures and their arguments takes awhile
- allow Mono.Data.Sql to build SQL for SELECT, INSERT, UPDATE, DELETE statements for a given table
- connection error handling.  When a connectione exception happens, the error is silent and IsOpen is set to false.
  We could add a property like ErrorMessage would return the error message from an exception.  This way, the user
  of the DbProvider would get the ErrorMessage if Open() returns false.  Or create an absract DbProviderError class to handle
  errors gracefully
- create collection classes instead of arrays for the schema types: TableSchemaCollection for TableSchema
- ProcedureSchema needs a way to indicate it is a "package" containing procedures and functions (this is to support
  Oracle packages which can contain stored procedures and functions).
  Maybe have two properties: bool HasSubProcedures and ProcedureSchema[] SubProcedures
- ProcedureSchema should provide a way to return the source of the stored procedure (the CREATE PROCEDURE SQL).
  An Oracle Package would include two parts: CREATE PACKAGE and the CREATE PACKAGE BODY
- ParameterSchema needs a property called Direction (input, output, input/output, return).  
- create an abstract class to create a test procedure so you can test/debug a procedure
- abstract support for debugging of stored procedures
- have DataTypeSchema to list available primitive types.  
- List available pre-defined types available like varchar, date, blob, etc... put in an array of DataTypeSchema
- add these Properties to DataTypeSchema for the above 
  can be used for a database table editor or data migration:
  * have a Length or not.  Valid minium/maximum range
  * have a Precision and Scale or not.  Valid min/max range for precision and scale. In Oracle scale can be negative.
  * is type a large object?  blob or clob in oracle, text or image in sql server, etc...
  * is binary like blob or raw or binary
  * is character like char or varchar
  * is multibyte character like nchar or nvarchar
  * other attributes, such as, a int in sql server can be an identity column with a seed starting at 1 step 1 (think autonumber)
  * has padding, such as, char (but not varchar) pad with spaces if value has length less then defined size
  * can be empty (have zero length).  varchar in sql server can have an empty string while a clob in oracle can be not null but empty.
  * is integer like: byte, smallint, int, bigint
  * is numeric like: number, numeric, decimal (i'm not sure if this should include integer types or not), but types
    like decimal have precision and scale
- need to get abstract command builder from provider factory
- if a command builder is not available for a given data provider or is not set in config file for provider,
  then create a class to build insert, update, and delete statements like command builder does.  Use
  parameterprefix in provider factory for this to determine what kind of parameter to add/use, or use xml db provider
- create a class as a db data provider but for xml (think the DataSet saved as xml and later loaded)
- create a DataMigration class to copy a table (definition and data) from one data source to another (optionally with constraints, keys, indexes, etc...)
  which can be used in a GUI app to import tables from one database to another.  If command builder available, use it.  If not, use
  a special command builder or the xml db provider


Future ADO.NET 2.0 Direction in Dot Net 2.0 
- if using ADO.NET 2.0 and a provider supports the ADO.NET 2.0 features, use the ADO.NET 2.0 features 
  for the metadata
  
  