squirrel-sql-develop Mailing List for SQuirreL SQL Client (Page 39)

On Wed, 20 Aug 2003 08:07 am, Joseph Boyd wrote:
> Squirrel (1.2b3) has a bug related to the title of the window that pops
> up when you double-click a cell in the results table.
>
> If you have re-arranged the table columns by dragging them around, the
> title displayed in the pop-up window does not reflect the new order of
> the columns.
>
> This is essentially the same bug I posted about previously, where
> copy/paste of re-arranged columns was broken, it's just in a different
> place.  It's essentially the same fix, too.  After I noticed the first
> bug, I was sort of grep-ing through the source, looking for similar
> bugs.  I found one.
>
>
> Attached is a patch to CellDataPopup.java that corrects the problem.
> Let me know if there are any problems.
>
>
> Enjoy.
>
>
> ...Joseph Boyd
>
> Lead Application Developer
> accessIndiana..."linking hoosiers to government"
> http://www.IN.gov
> 10 West Market St., Suite 600
> Indianapolis, IN 46204

Thanks Joseph, this has been applied to CVS.

-- 
Colin Bell
http://squirrel-sql.sf.net

Squirrel (1.2b3) has a bug related to the title of the window that pops 
up when you double-click a cell in the results table.

If you have re-arranged the table columns by dragging them around, the 
title displayed in the pop-up window does not reflect the new order of 
the columns.

This is essentially the same bug I posted about previously, where 
copy/paste of re-arranged columns was broken, it's just in a different 
place.  It's essentially the same fix, too.  After I noticed the first 
bug, I was sort of grep-ing through the source, looking for similar 
bugs.  I found one.


Attached is a patch to CellDataPopup.java that corrects the problem. 
Let me know if there are any problems.


Enjoy.


...Joseph Boyd

Lead Application Developer
accessIndiana..."linking hoosiers to government"
http://www.IN.gov
10 West Market St., Suite 600
Indianapolis, IN 46204

Thanks Joseph, this has been applied to CVS.

-- 
Colin Bell
http://squirrel-sql.sf.net



On Tue, 5 Aug 2003 06:07 am, Joseph Boyd wrote:
> Squirrel (1.2b3) has a bug related to copying table data from the table
> of results.
>
> If you have re-arranged the table columns by dragging them around, when
> you copy data from those columns, the column headers are NOT
> re-arranged, even though the column data values are.
>
> The attached two patches fix this problem for regular and HTML copy
> commands, properly copying data to the clipboard with the column headers
> re-arranged.
>
>
> Please let me know if I'm not submitting patches correctly, or if I've
> somehow missed the point with the patches themselves.
>
>
> btw, I submitted these same patches back in March, but I think they got
> lost in the shuffle.
>
>
>
> Regards,
>
> ...Joseph Boyd
>
> Lead Application Developer
> accessIndiana..."linking hoosiers to government"
> http://www.IN.gov
> 10 West Market St., Suite 600
> Indianapolis, IN 46204

Hi Joseph,

Sorry for missing your patches the first time, not sure what happened there.
I'm away for the next few days but will take a look at them when I get back
next week.

Thanks
Col

> -----Original Message-----
> From: Joseph Boyd [mailto:jb...@ww...]
> Sent: Tuesday, 5 August 2003 6:07
> To: squ...@li...
> Subject: [Squirrel-sql-develop] Copy/Paste of re-arranged Columns bug
> 
> 
> Squirrel (1.2b3) has a bug related to copying table data from 
> the table 
> of results.
> 
> If you have re-arranged the table columns by dragging them 
> around, when 
> you copy data from those columns, the column headers are NOT 
> re-arranged, even though the column data values are.
> 
> The attached two patches fix this problem for regular and HTML copy 
> commands, properly copying data to the clipboard with the 
> column headers 
> re-arranged.
> 
> 
> Please let me know if I'm not submitting patches correctly, 
> or if I've 
> somehow missed the point with the patches themselves.
> 
> 
> btw, I submitted these same patches back in March, but I 
> think they got 
> lost in the shuffle.
> 
> 
> 
> Regards,
> 
> ...Joseph Boyd
> 
> Lead Application Developer
> accessIndiana..."linking hoosiers to government"
> http://www.IN.gov
> 10 West Market St., Suite 600
> Indianapolis, IN 46204
> 
> 
> 

Squirrel (1.2b3) has a bug related to copying table data from the table 
of results.

If you have re-arranged the table columns by dragging them around, when 
you copy data from those columns, the column headers are NOT 
re-arranged, even though the column data values are.

The attached two patches fix this problem for regular and HTML copy 
commands, properly copying data to the clipboard with the column headers 
re-arranged.


Please let me know if I'm not submitting patches correctly, or if I've 
somehow missed the point with the patches themselves.


btw, I submitted these same patches back in March, but I think they got 
lost in the shuffle.



Regards,

...Joseph Boyd

Lead Application Developer
accessIndiana..."linking hoosiers to government"
http://www.IN.gov
10 West Market St., Suite 600
Indianapolis, IN 46204

Thanks, I'll make those changes.

-----Original Message-----
From: KosherJava [mailto:kos...@od...]
Sent: Sunday, 27 July 2003 15:35
To: squ...@li...
Subject: [Squirrel-sql-develop] javac -target and other options for Build



Hi,

I was looking at the build.xml and have 2 comments.

a) Since SQuirreL will not run on a JVM <1.3 why not set the target
attribute in the javac task in ant to 1.3 (as in target="1.3") ? this will
abort any attempt to run it on a jvm < 1.3. This will prevent bug reports
for lower JVMs. It might also be a good idea to set the bootclasspath to the
1.4 rt.jar (see link below)

 

b) includeJavaRuntime="yes" is not needed  (nor is it recommended, see link
below) . All this does is add rt.jar to the classpath.

 

For more on the subject I recommend reading:

http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version_p.html
<http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version_p.html> 

 

Hi Marco,

The catalog combo is built in the sequence the the driver returns the
catalog names in. In the future this will be sorted.

Col

> -----Original Message-----
> From: Marco Ceccarelli [mailto:m.c...@tn...]
> Sent: Friday, 25 July 2003 17:33
> To: squ...@li...
> Subject: [Squirrel-sql-develop] version 1.2beta (but also 
> prior) catalog
> combo disordered
> 
> 
> Hi, the catalog combo is disordered, it would be 
> alphabetically ordered no?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
> _072303_01/01
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
> 

Hi, 
I was looking at the build.xml and have 2 comments. 
a) Since SQuirreL will not run on a JVM <1.3 why not set the target attribute in the javac task in ant to 1.3 (as in target="1.3") ? this will abort any attempt to run it on a jvm < 1.3. This will prevent bug reports for lower JVMs. It might also be a good idea to set the bootclasspath to the 1.4 rt.jar (see link below) 
  
b) includeJavaRuntime="yes" is not needed  (nor is it recommended, see link below) . All this does is add rt.jar to the classpath. 
  
For more on the subject I recommend reading: 
http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version_p.html 
  

Hi, the catalog combo is disordered, it would be alphabetically ordered no?

Hi Thomas,

> 1. How do I retrieve the data of all tables (IDatabaseInfo[]) 
> contained in
> the user view
> of the current session.

mySession.getSQLConnection().getSQLMetaData().getTables(catalog,
schemaPattern, tableNamePattern, types);
							
> 2. How do I add an ISQLExecutionListener to the session.
> (previous Release and current CVS: addSQLExecutionListener())

mySession.getSQLPanelAPI(plugin).addSQLExecutionListener(lis);

> 3. How do I retrieve the data of a table (IDatabaseInfo) from the 
> objecttree using the tablename.

See the answer to 1 above.

--
Colin Bell
http://squirrel-sql.sf.net

----- Original Message -----
From: Thomas Kiebel <ki...@ma...>
Date: Tuesday, July 22, 2003 9:04 pm
Subject: [Squirrel-sql-develop] Table Meta Data Access

> Hello,
> 
> I currently work on a plugin for Squirrel_SQL based on the 1.1final1.
> I'm having problems using the ISession interfaces. Could someone 
> help and
> tell me:
> 
> 1. How do I retrieve the data of all tables (IDatabaseInfo[]) 
> contained in
> the user view
> of the current session.
> 
> 2. How do I add an ISQLExecutionListener to the session.
> (previous Release and current CVS: addSQLExecutionListener())
> 
> 3. How do I retrieve the data of a table (IDatabaseInfo) from the 
> objecttree using the tablename.
> 
> Thanks...
> 
> Thomas

 

Hi all,

After spending some time in the code, my best guess is that it is not 
Colin's fault.  I think it is probably an Oracle driver issue.

In the two cases mentioned, the code actually asks slightly different 
questions:

	- in the SQL results case, it asks "What are the columns associated with 
THIS result?"  This comes from getting the MetaData associated with the 
result set generated by the query.

	- in the Contents case (actually the Columns tab) it asks "What are the 
columns in this TABLE?"  This comes from the 
DataBaseMetaData.getColumns() method.  We cannot get this info from the 
ResultSet because the user may not have looked at the table contents 
before selecting the Columns tab, so there may be no result set.

Now, in a rational world one would tend to expect that the answers to 
those two questions would be the same, but since we are talking about a 
huge amount of code in the DBMS driver, it may not be too surprizing if 
they give different answers.  Since I don't have Oracle here, I can't 
run any tests (e.g. using a debugger to look at the actual ResultSets 
returned by the two requests to the driver), but that is my best guess.

Unfortunately, this means that we cannot trust the data in the Columns 
tab, which will make some of our development and debugging harder.

I'm going to proceed on the assumption that the MetaData associated with 
the data read from the table is more likely to be correct than the 
results of asking the DB MetaData about the table.  This assumption is 
based only on the info in this discussion, so it could be off-base.

Colin: This explains why CLOBs in the Contents tab work correctly in 
Oracle, and why turning off the string representation works as expected. 
  The data used in those cases comes from the MetaData from the 
generated ResultSet, not from the DB MetaData columns() method.

Glenn

Colin Bell wrote:

> Hi All,
> 
> The Oracle problem with data types looks at least partially to be a bug in
> SQuirreL. I haven't fully checked it out yet but the fact that if you run a
> SELECT statement over a table with a blob column in it the meta data tab
> shows the data type as '2005', the same column in the contents tab shows as
> '1111' strngly suggests a problem with the contents tab, probably been there
> since the first release of SQuirreL.
> 
> For anybody whose playing with Oracle I've attached a patch that will fix a
> problem displaying blob/clob columns when executing SQL from the SQL entry
> area. Currently it throws a NumberFormatException.
> 
> Glenn, could you please apply this patch and include it with your next set
> of changes to the data editing code? I didn't want to apply it myself
> because I know you're heavily modifying this area of the code.
> 
> Col
> 
> 
> 
>>-----Original Message-----
>>From: Maury Hammel [mailto:mh...@cr...]
>>Sent: Saturday, 19 July 2003 11:21
>>Cc: Squ...@li...
>>Subject: Re: [Squirrel-sql-develop] Another question about 1.2 beta
>>
>>
>>I created a few dummy tables using all of the 'primitive' 
>>data types in Oracle, 
>>here are the results for the data types:
>>
>>TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
>>---------------     ---------------      ------------------------
>>VARCHAR2            12                   VARCHAR
>>NVARCHAR2           1111                 OTHER
>>NUMBER              3                    DECIMAL
>>LONG                -1                   LONGVARCHAR
>>DATE                93                   TIMESTAMP
>>TIMESTAMP           1111                 OTHER
>>INTERVAL YEAR       1111                 OTHER
>>INTERVAL DAY        1111                 OTHER
>>RAW                 -3                   VARBINARY
>>LONG RAW            -4                   LONGVARBINARY
>>ROWID               1111                 OTHER
>>UROWID              1111                 OTHER
>>CHAR                1                    CHAR
>>NCHAR               1111                 OTHER
>>CLOB                1111                 OTHER
>>NCLOB               1111                 OTHER
>>BLOB                1111                 OTHER
>>BFILE               1111                 OTHER
>>
>>Trust an Oracle JDBC Driver to report more than half the 
>>datatypes as 'OTHER'. 
>>:-(  Looking at Oracle's JDBC programming documentation, I'm 
>>wondering if some 
>>of these numbers are due to bugs in the driver.  The 
>>documentation implies that 
>>BLOB and CLOB should  be identified by the proper 
>>java.sql.Types.* item.
>>
>>
>>Maury...
>>-- 
>>
>>Maury Hammel
>>Cronus Technologies Inc.
>>
>>http://www.cronustech.com
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a 
>>single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
>>machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Squirrel-sql-develop mailing list
>>Squ...@li...
>>https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
>>
>>
> 
> ResultSetDataSet.diff
> 
> Content-Type:
> 
> application/octet-stream
> Content-Encoding:
> 
> quoted-printable
> 
> 

Hello,

I currently work on a plugin for Squirrel_SQL based on the 1.1final1.
I'm having problems using the ISession interfaces. Could someone help and
tell me:

1. How do I retrieve the data of all tables (IDatabaseInfo[]) contained in
the user view
of the current session.

2. How do I add an ISQLExecutionListener to the session.
(previous Release and current CVS: addSQLExecutionListener())

3. How do I retrieve the data of a table (IDatabaseInfo) from the object
tree using the tablename.

Thanks...

Thomas

The Syntax Highlighting plugin has been updated to 0.11 and a new SQL
Edit Extras plugin has been released. Both of these plugins require
SQuirreL 1.2beta3.

SQL Edit Extras
===============
This plugin provides search and replace functionality, adding and
removing Java quoting around SQL and formating of SQL in the SQL entry
area.

https://sourceforge.net/project/showfiles.php?group_id=28383&release_id=172854


Syntax Highlighting
===================

Enhancements
------------
- Syntax highlighting can now be applied to table names.

Bug Fixes
---------
- Fix for selecting which SQL gets executed. When the cursor is
  on a line in the SQL entry that contains at least part of an SQL
  statement then only that SQL statment should be executed.

http://sourceforge.net/project/showfiles.php?group_id=28383&release_id=172677


--
Colin Bell
http://squirrel-sql.sf.net

 

The third beta of 1.2 is now available. This is mainly a bug fix release.

The changes are:

Enhancements
------------
- Contents tab has been made the default when first displaying
  table in Object view (Glenn Griffin).

Bug Fixes
---------
- Fix for selecting which SQL gets executed. When the cursor is
  on a line in the SQL entry that contains at least part of an
  SQL statement then only that SQL statment should be
  executed.
- Don't save duplicates in SQL history.
- Only load SQL history once.

The homepage can be found at http://squirrel-sql.sf.net and downloads 
are at 
http://sourceforge.net/project/showfiles.php?group_id=28383&release_id=172674


--
Colin Bell
http://squirrel-sql.sf.net
 

Folks,
The fix has been put into CVS.

Glenn

Colin Bell wrote:

> Hi All,
> 
[snip]
> 
> For anybody whose playing with Oracle I've attached a patch that will fix a
> problem displaying blob/clob columns when executing SQL from the SQL entry
> area. Currently it throws a NumberFormatException.
> 
> Glenn, could you please apply this patch and include it with your next set
> of changes to the data editing code? I didn't want to apply it myself
> because I know you're heavily modifying this area of the code.
> 
> Col
> 
> 

Hi All,

The Oracle problem with data types looks at least partially to be a bug in
SQuirreL. I haven't fully checked it out yet but the fact that if you run a
SELECT statement over a table with a blob column in it the meta data tab
shows the data type as '2005', the same column in the contents tab shows as
'1111' strngly suggests a problem with the contents tab, probably been there
since the first release of SQuirreL.

For anybody whose playing with Oracle I've attached a patch that will fix a
problem displaying blob/clob columns when executing SQL from the SQL entry
area. Currently it throws a NumberFormatException.

Glenn, could you please apply this patch and include it with your next set
of changes to the data editing code? I didn't want to apply it myself
because I know you're heavily modifying this area of the code.

Col


> -----Original Message-----
> From: Maury Hammel [mailto:mh...@cr...]
> Sent: Saturday, 19 July 2003 11:21
> Cc: Squ...@li...
> Subject: Re: [Squirrel-sql-develop] Another question about 1.2 beta
> 
> 
> I created a few dummy tables using all of the 'primitive' 
> data types in Oracle, 
> here are the results for the data types:
> 
> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
> ---------------     ---------------      ------------------------
> VARCHAR2            12                   VARCHAR
> NVARCHAR2           1111                 OTHER
> NUMBER              3                    DECIMAL
> LONG                -1                   LONGVARCHAR
> DATE                93                   TIMESTAMP
> TIMESTAMP           1111                 OTHER
> INTERVAL YEAR       1111                 OTHER
> INTERVAL DAY        1111                 OTHER
> RAW                 -3                   VARBINARY
> LONG RAW            -4                   LONGVARBINARY
> ROWID               1111                 OTHER
> UROWID              1111                 OTHER
> CHAR                1                    CHAR
> NCHAR               1111                 OTHER
> CLOB                1111                 OTHER
> NCLOB               1111                 OTHER
> BLOB                1111                 OTHER
> BFILE               1111                 OTHER
> 
> Trust an Oracle JDBC Driver to report more than half the 
> datatypes as 'OTHER'. 
> :-(  Looking at Oracle's JDBC programming documentation, I'm 
> wondering if some 
> of these numbers are due to bugs in the driver.  The 
> documentation implies that 
> BLOB and CLOB should  be identified by the proper 
> java.sql.Types.* item.
> 
> 
> Maury...
> -- 
> 
> Maury Hammel
> Cronus Technologies Inc.
> 
> http://www.cronustech.com
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a 
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
> 

I created a few dummy tables using all of the 'primitive' data types in Oracle, 
here are the results for the data types:

TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
---------------     ---------------      ------------------------
VARCHAR2            12                   VARCHAR
NVARCHAR2           1111                 OTHER
NUMBER              3                    DECIMAL
LONG                -1                   LONGVARCHAR
DATE                93                   TIMESTAMP
TIMESTAMP           1111                 OTHER
INTERVAL YEAR       1111                 OTHER
INTERVAL DAY        1111                 OTHER
RAW                 -3                   VARBINARY
LONG RAW            -4                   LONGVARBINARY
ROWID               1111                 OTHER
UROWID              1111                 OTHER
CHAR                1                    CHAR
NCHAR               1111                 OTHER
CLOB                1111                 OTHER
NCLOB               1111                 OTHER
BLOB                1111                 OTHER
BFILE               1111                 OTHER

Trust an Oracle JDBC Driver to report more than half the datatypes as 'OTHER'. 
:-(  Looking at Oracle's JDBC programming documentation, I'm wondering if some 
of these numbers are due to bugs in the driver.  The documentation implies that 
BLOB and CLOB should  be identified by the proper java.sql.Types.* item.


Maury...
-- 

Maury Hammel
Cronus Technologies Inc.

http://www.cronustech.com

I'll check at work on Monday.

Glenn wrote:

> The Firebird/Interbase documents say their BLOB has 3 sub-types, and 
> depending on the sub-type code it gets stored as a BLOB, LONGVARBINARY, 
> or LOGVARCHAR.  (Just happened to read this 5 minutes ago.  Good 
> coincidence.)  Maybe that's what's happening in Mimer?
> BTW - I haven't yet seen how to specify the sub-type :-)
> 
> Colin - One of the folks in this discussion said that Oracle does have a 
> "real" BLOB type.  Did you check to see if there was a type with code 
> 2004 but under a different name?
> 
> Glenn
> 
> Colin Bell wrote:
> 
>> Bloody Oracle.
>>
>> I've just done some checking with some other DBMs's
>>
>> DB2
>>
>> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
>> ---------------     ---------------      ------------------------
>> TIME                92                   java.sql.Types.TIME
>> DATE                91                   java.sql.Types.DATE
>> TIMESTAMP           93                   java.sql.Types.TIMESTAMP
>> BLOB                2004                 java.sql.Types.BLOB
>> CLOB                2005                 java.sql.Types.CLOB
>>
>>
>> Microsoft SQL Server
>>
>> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
>> ---------------     ---------------      ------------------------
>> DATETIME            93                   java.sql.Types.TIMESTAMP
>> IMAGE               -4                   java.sql.Types.LONGVARBINARY
>> TEXT                -1                   java.sql.Types.LONGVARCHAR
>> MONEY               3                    java.sql.Types.DECIMAL
>> BINARY              -2                   java.sql.Types.BINARY
>>
>>
>> Mimer
>>
>> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
>> ---------------     ---------------      ------------------------
>> TIMESTAMP           93                   java.sql.Types.TIMESTAMP
>> DATE                91                   java.sql.Types.DATE
>> BINARY LARGE OBJECT    -4                   java.sql.Types.LONGVARBINARY
>> BINARY LARGE OBJECT    2004                 java.sql.Types.BLOB
>>
>>
>> The binary large object is interesting. The column definitions for the
>> table reported the same column name twice, once as -4 and once as 2004.
>> When I tried to display the table in SQSC I got a java.sql.SQLException:
>> Numeric value out of range
>> The problem mightn't be too bad. Oracles problematical and obviously we
>> need to check a few more databases but I would hope that most DBMS's get
>> this information correct.
>>
>> -- 
>> Colin Bell
>> http://squirrel-sql.sf.net
>>
>> ----- Original Message -----
>> From: gwg <gw...@co...>
>> Date: Friday, July 18, 2003 9:15 am
>> Subject: Re: [Squirrel-sql-develop] Another question about 1.2 beta
>>
>>
>>> Maury,
>>> Thanks for looking them up...
>>>
>>> Maury Hammel wrote:
>>>
>>>
>>>> Glenn:
>>>>
>>>>
>>>>> Well, that depends....
>>>>> The data type in the DBMS gets mapped to a SQL type code
>>>
>>> somewhere
>>>
>>>>> (either in the DBMS or in the Java driver - I don't know). 
>>>
>>> There is a
>>>
>>>>> list of standard "known" codes in java.sql.Types.java, but
>>>
>>> every DBMS
>>>
>>>>> I've seen so far implements lots of other data types that do
>>>
>>> not map
>>>
>>>>> to codes in that file.  The only codes that we can reliably
>>>
>>> build
>>>
>>>>> editors for are those in the Types.java file (since different
>>>
>>> DBMSs
>>>
>>>>> might use the same non-standard code for different purposes).  
>>>>> Therefore, to know if we will be able to create an editor for
>>>
>>> the
>>>
>>>>> NUMBER type, we will need to know the SQL code used by Oracle
>>>
>>> for that
>>>
>>>>> type.  This can be found in the COLUMNS tab field named
>>>
>>> "DATA_TYPE". 
>>>
>>>>> If you let me know what that number is, I can tell you if it is 
>>>>> possible to make an editor for it, but we still won't know
>>>
>>> whether
>>>
>>>>> we'll get around to it or not.
>>>>>
>>>>
>>>> Ah, okay.  I did a quick check of some databases and got the
>>>
>>> types that
>>>
>>>> don't appear to be editable:
>>>>
>>>> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
>>>> ---------------     ---------------      ------------------------
>>>>
>>> -
>>>
>>>> NUMBER              3                    java.sql.Types.DECIMAL
>>>> DATE                93                   java.sql.Types.TIMESTAMP
>>>> TIMESTAMP           1111                 java.sql.Types.OTHER
>>>> BLOB                1111                 java.sql.Types.OTHER
>>>> CLOB                1111                 java.sql.Types.OTHER
>>>>
>>>> Ugh, I don't like the look of the TIMESTAMP, BLOB and CLOB
>>>
>>> values.  Can
>>>
>>>> you not base the decision about editing on the "TYPE_NAME"
>>>
>>> column?  Or
>>>
>>>> will there be the API to allow a database-specific plug-in to
>>>
>>> handle the
>>>
>>>> 'OTHER's?
>>>>
>>>
>>> I don't like their looks either :-).
>>>
>>> The problem is how to handle things that do not have a "standard" 
>>> type associated with them.  What java object are they transformed 
>>> into internally?  What rules do we allow/disallow on editing of the 
>>> string representation of that type?
>>>
>>> The 3 OTHERs listed here are prime examples of the problems.  Each 
>>> DBMS seems to have its own representation of TIMESTAMP, and there is 
>>> no guarantee that they would look or work the same from one DBMS to 
>>> another.  Does your DMBS include milliseconds?  Yes?  Well too bad - 
>>> we couldn't include those because someone else's DBMS does not allow 
>>> them. Your DBMS wants TIMESTAMPs as "hh:mm:ss"?  Well your neighbor's 
>>> stores them in "seconds since beginning of the epoch".  You get the 
>>> idea.
>>>
>>> BLOBs and CLOBs are even worse.  You may have noticed in 
>>> java.sql.Types that BLOB and CLOB have special codes of their own 
>>> (2004 & 2005 respectivly).  These have special meaning since they are 
>>> handled by Blob and Clob objects within Java.  When you get the data 
>>> from the resultset, you read it into a Blob/Clob object which does 
>>> _not_ include the actual data.  That column data is read from the DB 
>>> by making a call on the Blob/Clob object.  Since Oracle maps 
>>> type-name "BLOB" to java.sql.Type.OTHER, it would not use that 
>>> 2-stage mechanism, and thus would not operate as a "BLOB" should, 
>>> even though it has that name. (Actually, this surprises the heck out 
>>> of me since I had the impression from some info from Colin that 
>>> Oracle had real BLOB/CLOB types, not something fudged.  By the way, 
>>> every DBMS I've been able to get running on my machine uses some 
>>> funky non-standard BLOB/CLOB mechanism while calling the types "BLOB" 
>>> and "CLOB".  Postgess actually stores them as LONGVARBINARY objects!)
>>>
>>> So you see my problem is how to handle things consistantly from DBMS 
>>> to DBMS when the DMBS manufacturers haven't agreed on how to handle 
>>> things consistantly.  I really think that relying on the name would 
>>> get us in trouble (witness the "BLOB/CLOB" case).  I haven't thought 
>>> about the DBMS-specific plug-in approach, but that might work.  Any 
>>> other good ideas?
>>>
>>> Glenn
>>>
>>>
>>>
>>>>
>>>> Maury...
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: VM Ware
>>> With VMware you can run multiple operating systems on a single 
>>> machine.WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
>>> machines at the
>>> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>> _______________________________________________
>>> Squirrel-sql-develop mailing list
>>> Squ...@li...
>>> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
>>>
>>>
>>  
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: VM Ware
>> With VMware you can run multiple operating systems on a single machine.
>> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>> _______________________________________________
>> Squirrel-sql-develop mailing list
>> Squ...@li...
>> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
> 


-- 
Colin Bell
http://squirrel-sql.sf.net

Maury Hammel wrote:

> Glenn:
> 
>> My gut feeling is that Maury's idea of including DBMS-specific 
>> renderer/editor classes in plugins could work.  There is already an 
>> interface that the DataType classes need to use (currently only used 
>> internally in the core code, but what the heck).  We'ld need to add a 
>> way for the plug-in to register a class to associate it with a given 
>> SQL type code, but that should be easy to do.  Then it would be "just" a 
> 
> 
> There would have to be more to it than just have a plug-in registering a 
> class based on the Type code, as we've got databases that use the same 
> type code for multiple data types (as we saw with the Oracle database).


Given that different DBMSs could use the same code for different data 
types, you're probably right.  Without looking into it, I'm reasonably 
confident that the DB identification and table name could be passed in.


> 
> On the other hand, maybe it is.  However, the registering class from the 
> plug-in, when it is invoked, would have to be sent all the metadata 
> information about the column in question, so that it could make 
> intelligent decisions about what needs to be done to for that type of 
> column -- this would be very important for java.sql.Types.OTHER, but 
> would probably still be required for some of the other types as well 
> (e.g. precision and scale values for numeric values).


Yup.  The DataType components currently take a ColumnDisplayDefinition 
object in the constructor, from which they can extract those kinds of 
things.  If you like, take a look at fw.datasetviewer.cellcomponent 
where CellComponentFactory creates instances of DataTypeInteger and 
DataTypeString objects.  I guess that we would need to put the 
constructor definition into IDataTypeComponet, but the basic idea is there.

Something to be careful of is that some/many/all DBMSs do not fill in 
that info.  At least the ones that I've been playing with don't.  Of 
course, if you are building a DBMS-specific class, you can check out 
what that DBMS provides and use what's available.


> 
>  > matter of finding people willing to do the codeing and testing. :-)
> 
> Yeah, I guess I can volunteer to do some stuff for Oracle, once you've 
> got the interface/API nailed down.
> 
> 
> Maury...


Okay.  Don't know when that will be.

Glenn

The Firebird/Interbase documents say their BLOB has 3 sub-types, and 
depending on the sub-type code it gets stored as a BLOB, LONGVARBINARY, 
or LOGVARCHAR.  (Just happened to read this 5 minutes ago.  Good 
coincidence.)  Maybe that's what's happening in Mimer?
BTW - I haven't yet seen how to specify the sub-type :-)

Colin - One of the folks in this discussion said that Oracle does have a 
"real" BLOB type.  Did you check to see if there was a type with code 
2004 but under a different name?

Glenn

Colin Bell wrote:

> Bloody Oracle.
> 
> I've just done some checking with some other DBMs's
> 
> DB2
> 
> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
> ---------------     ---------------      ------------------------
> TIME                92                   java.sql.Types.TIME
> DATE                91                   java.sql.Types.DATE
> TIMESTAMP           93                   java.sql.Types.TIMESTAMP
> BLOB                2004                 java.sql.Types.BLOB
> CLOB                2005                 java.sql.Types.CLOB
> 
> 
> Microsoft SQL Server
> 
> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
> ---------------     ---------------      ------------------------
> DATETIME            93                   java.sql.Types.TIMESTAMP
> IMAGE               -4                   java.sql.Types.LONGVARBINARY
> TEXT                -1                   java.sql.Types.LONGVARCHAR
> MONEY               3                    java.sql.Types.DECIMAL
> BINARY              -2                   java.sql.Types.BINARY
> 
> 
> Mimer
> 
> TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
> ---------------     ---------------      ------------------------
> TIMESTAMP           93                   java.sql.Types.TIMESTAMP
> DATE                91                   java.sql.Types.DATE
> BINARY LARGE OBJECT	-4                   java.sql.Types.LONGVARBINARY
> BINARY LARGE OBJECT	2004                 java.sql.Types.BLOB
> 
> 
> The binary large object is interesting. The column definitions for the
> table reported the same column name twice, once as -4 and once as 2004.
> When I tried to display the table in SQSC I got a java.sql.SQLException:
> Numeric value out of range 
> 
> The problem mightn't be too bad. Oracles problematical and obviously we
> need to check a few more databases but I would hope that most DBMS's get
> this information correct.
> 
> --
> Colin Bell
> http://squirrel-sql.sf.net
> 
> ----- Original Message -----
> From: gwg <gw...@co...>
> Date: Friday, July 18, 2003 9:15 am
> Subject: Re: [Squirrel-sql-develop] Another question about 1.2 beta
> 
> 
>>Maury,
>>Thanks for looking them up...
>>
>>Maury Hammel wrote:
>>
>>
>>>Glenn:
>>>
>>>
>>>>Well, that depends....
>>>>The data type in the DBMS gets mapped to a SQL type code 
>>>>
>>somewhere 
>>
>>>>(either in the DBMS or in the Java driver - I don't know).  
>>>>
>>There is a 
>>
>>>>list of standard "known" codes in java.sql.Types.java, but 
>>>>
>>every DBMS 
>>
>>>>I've seen so far implements lots of other data types that do 
>>>>
>>not map 
>>
>>>>to codes in that file.  The only codes that we can reliably 
>>>>
>>build 
>>
>>>>editors for are those in the Types.java file (since different 
>>>>
>>DBMSs 
>>
>>>>might use the same non-standard code for different purposes).  
>>>>Therefore, to know if we will be able to create an editor for 
>>>>
>>the 
>>
>>>>NUMBER type, we will need to know the SQL code used by Oracle 
>>>>
>>for that 
>>
>>>>type.  This can be found in the COLUMNS tab field named 
>>>>
>>"DATA_TYPE".  
>>
>>>>If you let me know what that number is, I can tell you if it is 
>>>>possible to make an editor for it, but we still won't know 
>>>>
>>whether 
>>
>>>>we'll get around to it or not.
>>>>
>>>
>>>Ah, okay.  I did a quick check of some databases and got the 
>>>
>>types that 
>>
>>>don't appear to be editable:
>>>
>>>TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
>>>---------------     ---------------      ------------------------
>>>
>>-
>>
>>>NUMBER              3                    java.sql.Types.DECIMAL
>>>DATE                93                   java.sql.Types.TIMESTAMP
>>>TIMESTAMP           1111                 java.sql.Types.OTHER
>>>BLOB                1111                 java.sql.Types.OTHER
>>>CLOB                1111                 java.sql.Types.OTHER
>>>
>>>Ugh, I don't like the look of the TIMESTAMP, BLOB and CLOB 
>>>
>>values.  Can 
>>
>>>you not base the decision about editing on the "TYPE_NAME" 
>>>
>>column?  Or 
>>
>>>will there be the API to allow a database-specific plug-in to 
>>>
>>handle the 
>>
>>>'OTHER's?
>>>
>>
>>I don't like their looks either :-).
>>
>>The problem is how to handle things that do not have a "standard" 
>>type 
>>associated with them.  What java object are they transformed into 
>>internally?  What rules do we allow/disallow on editing of the 
>>string 
>>representation of that type?
>>
>>The 3 OTHERs listed here are prime examples of the problems.  Each 
>>DBMS 
>>seems to have its own representation of TIMESTAMP, and there is no 
>>guarantee that they would look or work the same from one DBMS to 
>>another.  Does your DMBS include milliseconds?  Yes?  Well too bad 
>>- we 
>>couldn't include those because someone else's DBMS does not allow 
>>them. 
>> Your DBMS wants TIMESTAMPs as "hh:mm:ss"?  Well your neighbor's 
>>stores 
>>them in "seconds since beginning of the epoch".  You get the idea.
>>
>>BLOBs and CLOBs are even worse.  You may have noticed in 
>>java.sql.Types 
>>that BLOB and CLOB have special codes of their own (2004 & 2005 
>>respectivly).  These have special meaning since they are handled 
>>by Blob 
>>and Clob objects within Java.  When you get the data from the 
>>resultset, 
>>you read it into a Blob/Clob object which does _not_ include the 
>>actual 
>>data.  That column data is read from the DB by making a call on 
>>the 
>>Blob/Clob object.  Since Oracle maps type-name "BLOB" to 
>>java.sql.Type.OTHER, it would not use that 2-stage mechanism, and 
>>thus 
>>would not operate as a "BLOB" should, even though it has that 
>>name. 
>>(Actually, this surprises the heck out of me since I had the 
>>impression 
>>from some info from Colin that Oracle had real BLOB/CLOB types, 
>>not 
>>something fudged.  By the way, every DBMS I've been able to get 
>>running 
>>on my machine uses some funky non-standard BLOB/CLOB mechanism 
>>while 
>>calling the types "BLOB" and "CLOB".  Postgess actually stores 
>>them as 
>>LONGVARBINARY objects!)
>>
>>So you see my problem is how to handle things consistantly from 
>>DBMS to 
>>DBMS when the DMBS manufacturers haven't agreed on how to handle 
>>things 
>>consistantly.  I really think that relying on the name would get 
>>us in 
>>trouble (witness the "BLOB/CLOB" case).  I haven't thought about 
>>the 
>>DBMS-specific plug-in approach, but that might work.  Any other 
>>good ideas?
>>
>>Glenn
>>
>>
>>
>>>
>>>Maury...
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single 
>>machine.WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
>>machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Squirrel-sql-develop mailing list
>>Squ...@li...
>>https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
>>
>>
>  
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
> 
> 

Bloody Oracle.

I've just done some checking with some other DBMs's

DB2

TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
---------------     ---------------      ------------------------
TIME                92                   java.sql.Types.TIME
DATE                91                   java.sql.Types.DATE
TIMESTAMP           93                   java.sql.Types.TIMESTAMP
BLOB                2004                 java.sql.Types.BLOB
CLOB                2005                 java.sql.Types.CLOB


Microsoft SQL Server

TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
---------------     ---------------      ------------------------
DATETIME            93                   java.sql.Types.TIMESTAMP
IMAGE               -4                   java.sql.Types.LONGVARBINARY
TEXT                -1                   java.sql.Types.LONGVARCHAR
MONEY               3                    java.sql.Types.DECIMAL
BINARY              -2                   java.sql.Types.BINARY


Mimer

TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
---------------     ---------------      ------------------------
TIMESTAMP           93                   java.sql.Types.TIMESTAMP
DATE                91                   java.sql.Types.DATE
BINARY LARGE OBJECT	-4                   java.sql.Types.LONGVARBINARY
BINARY LARGE OBJECT	2004                 java.sql.Types.BLOB


The binary large object is interesting. The column definitions for the
table reported the same column name twice, once as -4 and once as 2004.
When I tried to display the table in SQSC I got a java.sql.SQLException:
Numeric value out of range 

The problem mightn't be too bad. Oracles problematical and obviously we
need to check a few more databases but I would hope that most DBMS's get
this information correct.

--
Colin Bell
http://squirrel-sql.sf.net

----- Original Message -----
From: gwg <gw...@co...>
Date: Friday, July 18, 2003 9:15 am
Subject: Re: [Squirrel-sql-develop] Another question about 1.2 beta

> Maury,
> Thanks for looking them up...
> 
> Maury Hammel wrote:
> 
> > Glenn:
> > 
> >> Well, that depends....
> >> The data type in the DBMS gets mapped to a SQL type code 
> somewhere 
> >> (either in the DBMS or in the Java driver - I don't know).  
> There is a 
> >> list of standard "known" codes in java.sql.Types.java, but 
> every DBMS 
> >> I've seen so far implements lots of other data types that do 
> not map 
> >> to codes in that file.  The only codes that we can reliably 
> build 
> >> editors for are those in the Types.java file (since different 
> DBMSs 
> >> might use the same non-standard code for different purposes).  
> >> Therefore, to know if we will be able to create an editor for 
> the 
> >> NUMBER type, we will need to know the SQL code used by Oracle 
> for that 
> >> type.  This can be found in the COLUMNS tab field named 
> "DATA_TYPE".  
> >> If you let me know what that number is, I can tell you if it is 
> >> possible to make an editor for it, but we still won't know 
> whether 
> >> we'll get around to it or not.
> > 
> > 
> > Ah, okay.  I did a quick check of some databases and got the 
> types that 
> > don't appear to be editable:
> > 
> > TYPE_NAME value     DATA_TYPE value      java.sql.Types.?
> > ---------------     ---------------      ------------------------
> -
> > NUMBER              3                    java.sql.Types.DECIMAL
> > DATE                93                   java.sql.Types.TIMESTAMP
> > TIMESTAMP           1111                 java.sql.Types.OTHER
> > BLOB                1111                 java.sql.Types.OTHER
> > CLOB                1111                 java.sql.Types.OTHER
> > 
> > Ugh, I don't like the look of the TIMESTAMP, BLOB and CLOB 
> values.  Can 
> > you not base the decision about editing on the "TYPE_NAME" 
> column?  Or 
> > will there be the API to allow a database-specific plug-in to 
> handle the 
> > 'OTHER's?
> 
> 
> I don't like their looks either :-).
> 
> The problem is how to handle things that do not have a "standard" 
> type 
> associated with them.  What java object are they transformed into 
> internally?  What rules do we allow/disallow on editing of the 
> string 
> representation of that type?
> 
> The 3 OTHERs listed here are prime examples of the problems.  Each 
> DBMS 
> seems to have its own representation of TIMESTAMP, and there is no 
> guarantee that they would look or work the same from one DBMS to 
> another.  Does your DMBS include milliseconds?  Yes?  Well too bad 
> - we 
> couldn't include those because someone else's DBMS does not allow 
> them. 
>  Your DBMS wants TIMESTAMPs as "hh:mm:ss"?  Well your neighbor's 
> stores 
> them in "seconds since beginning of the epoch".  You get the idea.
> 
> BLOBs and CLOBs are even worse.  You may have noticed in 
> java.sql.Types 
> that BLOB and CLOB have special codes of their own (2004 & 2005 
> respectivly).  These have special meaning since they are handled 
> by Blob 
> and Clob objects within Java.  When you get the data from the 
> resultset, 
> you read it into a Blob/Clob object which does _not_ include the 
> actual 
> data.  That column data is read from the DB by making a call on 
> the 
> Blob/Clob object.  Since Oracle maps type-name "BLOB" to 
> java.sql.Type.OTHER, it would not use that 2-stage mechanism, and 
> thus 
> would not operate as a "BLOB" should, even though it has that 
> name. 
> (Actually, this surprises the heck out of me since I had the 
> impression 
> from some info from Colin that Oracle had real BLOB/CLOB types, 
> not 
> something fudged.  By the way, every DBMS I've been able to get 
> running 
> on my machine uses some funky non-standard BLOB/CLOB mechanism 
> while 
> calling the types "BLOB" and "CLOB".  Postgess actually stores 
> them as 
> LONGVARBINARY objects!)
> 
> So you see my problem is how to handle things consistantly from 
> DBMS to 
> DBMS when the DMBS manufacturers haven't agreed on how to handle 
> things 
> consistantly.  I really think that relying on the name would get 
> us in 
> trouble (witness the "BLOB/CLOB" case).  I haven't thought about 
> the 
> DBMS-specific plug-in approach, but that might work.  Any other 
> good ideas?
> 
> Glenn
> 
> 
> > 
> > 
> > Maury...
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single 
> machine.WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
> 
 

Glenn:

> My gut feeling is that Maury's idea of including DBMS-specific 
> renderer/editor classes in plugins could work.  There is already an 
> interface that the DataType classes need to use (currently only used 
> internally in the core code, but what the heck).  We'ld need to add a 
> way for the plug-in to register a class to associate it with a given SQL 
> type code, but that should be easy to do.  Then it would be "just" a 

There would have to be more to it than just have a plug-in registering a class 
based on the Type code, as we've got databases that use the same type code for 
multiple data types (as we saw with the Oracle database).

On the other hand, maybe it is.  However, the registering class from the 
plug-in, when it is invoked, would have to be sent all the metadata information 
about the column in question, so that it could make intelligent decisions about 
what needs to be done to for that type of column -- this would be very important 
for java.sql.Types.OTHER, but would probably still be required for some of the 
other types as well (e.g. precision and scale values for numeric values).

 > matter of finding people willing to do the codeing and testing. :-)

Yeah, I guess I can volunteer to do some stuff for Oracle, once you've got the 
interface/API nailed down.


Maury...
-- 

Maury Hammel
Cronus Technologies Inc.

http://www.cronustech.com

Hi Tolley,

I'd appreciate a patch that would trim the schema name for in
SQLDatabaseMetaData.getSchemas() for Ingres only. Doing it here rather
than in getTables() should mean that all usage of schemas should work
for Ingres, not just getTables(). Also doing it. for Ingres only means
it shouldn't break for DBMS's that allow embedded blanks in schema names.

--
Colin Bell
http://squirrel-sql.sf.net

----- Original Message -----
From: Tolley Shorn <Sho...@nr...>
Date: Friday, July 18, 2003 10:08 am
Subject: [Squirrel-sql-develop] Squirrel SQL and Ingres 2.6

> 
> Hi Folks,
> 
> I work on Ingres 2.6, with the driver supplied by CA.
> Unfortunately, the Ingres driver has a bug where the values 
> returned by the DatabaseMetaData.getSchemas() method can't then be 
> given straight back to the DatabaseMetaData .getTables() method 
> (the schema names returned have a bunch of spaces at the end).
> I fixed the issue by adding a single line to the Squirrel 
> framework
net.sourceforge.squirrel_sql.fw.sql.SQLDatabaseMetaData.getTables()
method that trimmed the schema name, but I'm thinking that the better
way to fix this is just to write a plugin for Squirrel that modifies the
schema name before Squirrel tries to use it to list the table names.
> 
> Unfortunately, I just don't have time right now to learn how to 
> write a Squirrel plugin.  
> I'm just wondering if anyone can confirm that I can intercept and 
> alter the schema name from within a plugin before Squirrel tries 
> to use it to list the tables?
> 
> If this can't be done I'd like to submit a patch for the 
> getTables() method that will trim the schema name before giving it 
> to the getTables() method.
> Unfortunately I don't have access to CVS from work because of 
> firewall and proxying issues.
> If I can't do what I need to do from a plugin, how do I submit a 
> patch for Squirrel (and will it be accepted?)
> If it needs to be a framework patch, I'd really like to get it in 
> before 1.2 goes final so that I can point people to a publicly 
> distributed version of Squirrel that will work with Ingres.
> 
> Cheers,
> Shorn.
> 
> 
> ************************************************************************
> The information in this e-mail together with any attachments is
> intended only for the person or entity to which it is addressed
> and may contain confidential and/or privileged material.
> Any form of review, disclosure, modification, distribution
> and/or publication of this e-mail message is prohibited.  
> If you have received this message in error, you are asked to
> inform the sender as quickly as possible and delete this message
> and any copies of this message from your computer and/or your
> computer system network.  
> ************************************************************************
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single 
> machine.WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Squirrel-sql-develop mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
> 
 

Yes, that is what would happen if the SQL type code is the one for 
TIMESTAMP.  In that case we know when we read the item from the 
resultset to use the get function that returns a java timestamp object 
(sorry for being fuzzy here - I don't have the interface info 
available).  The problem is that when re read the resultset we don't 
know what kind of object we are looking at because the database tells us 
that the SQL type for that field is a code that is not listed in 
java.sql.Types.  Therefore we dare not try to interpret the data because 
we do not know what it is.

My gut feeling is that Maury's idea of including DBMS-specific 
renderer/editor classes in plugins could work.  There is already an 
interface that the DataType classes need to use (currently only used 
internally in the core code, but what the heck).  We'ld need to add a 
way for the plug-in to register a class to associate it with a given SQL 
type code, but that should be easy to do.  Then it would be "just" a 
matter of finding people willing to do the codeing and testing. :-)

Glenn

KosherJava wrote:

> In regard to the Timestamp, Wouldn't Timestamp.valueOf(String) work? When you display the timestamp, Java always uses the format of: yyyy-MM-dd hh:mm:ss.fffffffff  and this is the format that valueOf expects. Since this is in the API documentation I would expect all drivers to adhere to it. The driver would then convert the Timestamp into the format expected by the DB. At least this is the way DB2 works. (natively it does not use the yyyy-MM-dd hh:mm:ss.fffffffff  format, but the Timestamp generated by valueOf() converts it to the properly formatted Timestap. 
>   
> -----Original Message----- 
>   
> Maury, 
> Thanks for looking them up... 
>   
> Maury Hammel wrote: 
>   
> 
>>Glenn: 
>>
>>
>>>Well, that depends.... 
>>>The data type in the DBMS gets mapped to a SQL type code somewhere 
>>>(either in the DBMS or in the Java driver - I don't know). There is a 
>>>list of standard "known" codes in java.sql.Types.java, but every DBMS 
>>>I've seen so far implements lots of other data types that do not map 
>>>to codes in that file. The only codes that we can reliably build 
>>>editors for are those in the Types.java file (since different DBMSs 
>>>might use the same non-standard code for different purposes). 
>>>Therefore, to know if we will be able to create an editor for the 
>>>NUMBER type, we will need to know the SQL code used by Oracle for that 
>>>type. This can be found in the COLUMNS tab field named "DATA_TYPE". 
>>>If you let me know what that number is, I can tell you if it is 
>>>possible to make an editor for it, but we still won't know whether 
>>>we'll get around to it or not. 
>>>
>>
>>Ah, okay. I did a quick check of some databases and got the types that 
>>don't appear to be editable: 
>>
>>TYPE_NAME value DATA_TYPE value java.sql.Types.? 
>>--------------- --------------- ------------------------- 
>>NUMBER 3 java.sql.Types.DECIMAL 
>>DATE 93 java.sql.Types.TIMESTAMP 
>>TIMESTAMP 1111 java.sql.Types.OTHER 
>>BLOB 1111 java.sql.Types.OTHER 
>>CLOB 1111 java.sql.Types.OTHER 
>>
>>Ugh, I don't like the look of the TIMESTAMP, BLOB and CLOB values. Can 
>>you not base the decision about editing on the "TYPE_NAME" column? Or 
>>will there be the API to allow a database-specific plug-in to handle the 
>>'OTHER's? 
>>
>   
> I don't like their looks either :-). 
>   
> The problem is how to handle things that do not have a "standard" type 
> associated with them. What java object are they transformed into 
> internally? What rules do we allow/disallow on editing of the string 
> representation of that type? 
>   
> The 3 OTHERs listed here are prime examples of the problems. Each DBMS 
> seems to have its own representation of TIMESTAMP, and there is no 
> guarantee that they would look or work the same from one DBMS to 
> another. Does your DMBS include milliseconds? Yes? Well too bad - we 
> couldn't include those because someone else's DBMS does not allow them. 
> Your DBMS wants TIMESTAMPs as "hh:mm:ss"? Well your neighbor's stores 
> them in "seconds since beginning of the epoch". You get the idea. 
>   
> BLOBs and CLOBs are even worse. You may have noticed in java.sql.Types 
> that BLOB and CLOB have special codes of their own (2004 & 2005 
> respectivly). These have special meaning since they are handled by Blob 
> and Clob objects within Java. When you get the data from the resultset, 
> you read it into a Blob/Clob object which does _not_ include the actual 
> data. That column data is read from the DB by making a call on the 
> Blob/Clob object. Since Oracle maps type-name "BLOB" to 
> java.sql.Type.OTHER, it would not use that 2-stage mechanism, and thus 
> would not operate as a "BLOB" should, even though it has that name. 
> (Actually, this surprises the heck out of me since I had the impression 
> from some info from Colin that Oracle had real BLOB/CLOB types, not 
> something fudged. By the way, every DBMS I've been able to get running 
> on my machine uses some funky non-standard BLOB/CLOB mechanism while 
> calling the types "BLOB" and "CLOB". Postgess actually stores them as 
> LONGVARBINARY objects!) 
>   
> So you see my problem is how to handle things consistantly from DBMS to 
> DBMS when the DMBS manufacturers haven't agreed on how to handle things 
> consistantly. I really think that relying on the name would get us in 
> trouble (witness the "BLOB/CLOB" case). I haven't thought about the 
> DBMS-specific plug-in approach, but that might work. Any other good ideas? 
>   
> Glenn 
>   
> 
>>
>>Maury... 
>>
>   
>   
> ------------------------------------------------------- 
> This SF.net email is sponsored by: VM Ware 
> With VMware you can run multiple operating systems on a single machine. 
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the 
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 
> _______________________________________________ 
> Squirrel-sql-develop mailing list 
> Squ...@li... 
> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop 
> 
> 

In regard to the Timestamp, Wouldn't Timestamp.valueOf(String) work? When you display the timestamp, Java always uses the format of: yyyy-MM-dd hh:mm:ss.fffffffff  and this is the format that valueOf expects. Since this is in the API documentation I would expect all drivers to adhere to it. The driver would then convert the Timestamp into the format expected by the DB. At least this is the way DB2 works. (natively it does not use the yyyy-MM-dd hh:mm:ss.fffffffff  format, but the Timestamp generated by valueOf() converts it to the properly formatted Timestap. 
  
-----Original Message----- 
  
Maury, 
Thanks for looking them up... 
  
Maury Hammel wrote: 
  
> Glenn: 
> 
>> Well, that depends.... 
>> The data type in the DBMS gets mapped to a SQL type code somewhere 
>> (either in the DBMS or in the Java driver - I don't know). There is a 
>> list of standard "known" codes in java.sql.Types.java, but every DBMS 
>> I've seen so far implements lots of other data types that do not map 
>> to codes in that file. The only codes that we can reliably build 
>> editors for are those in the Types.java file (since different DBMSs 
>> might use the same non-standard code for different purposes). 
>> Therefore, to know if we will be able to create an editor for the 
>> NUMBER type, we will need to know the SQL code used by Oracle for that 
>> type. This can be found in the COLUMNS tab field named "DATA_TYPE". 
>> If you let me know what that number is, I can tell you if it is 
>> possible to make an editor for it, but we still won't know whether 
>> we'll get around to it or not. 
> 
> 
> Ah, okay. I did a quick check of some databases and got the types that 
> don't appear to be editable: 
> 
> TYPE_NAME value DATA_TYPE value java.sql.Types.? 
> --------------- --------------- ------------------------- 
> NUMBER 3 java.sql.Types.DECIMAL 
> DATE 93 java.sql.Types.TIMESTAMP 
> TIMESTAMP 1111 java.sql.Types.OTHER 
> BLOB 1111 java.sql.Types.OTHER 
> CLOB 1111 java.sql.Types.OTHER 
> 
> Ugh, I don't like the look of the TIMESTAMP, BLOB and CLOB values. Can 
> you not base the decision about editing on the "TYPE_NAME" column? Or 
> will there be the API to allow a database-specific plug-in to handle the 
> 'OTHER's? 
  
I don't like their looks either :-). 
  
The problem is how to handle things that do not have a "standard" type 
associated with them. What java object are they transformed into 
internally? What rules do we allow/disallow on editing of the string 
representation of that type? 
  
The 3 OTHERs listed here are prime examples of the problems. Each DBMS 
seems to have its own representation of TIMESTAMP, and there is no 
guarantee that they would look or work the same from one DBMS to 
another. Does your DMBS include milliseconds? Yes? Well too bad - we 
couldn't include those because someone else's DBMS does not allow them. 
Your DBMS wants TIMESTAMPs as "hh:mm:ss"? Well your neighbor's stores 
them in "seconds since beginning of the epoch". You get the idea. 
  
BLOBs and CLOBs are even worse. You may have noticed in java.sql.Types 
that BLOB and CLOB have special codes of their own (2004 & 2005 
respectivly). These have special meaning since they are handled by Blob 
and Clob objects within Java. When you get the data from the resultset, 
you read it into a Blob/Clob object which does _not_ include the actual 
data. That column data is read from the DB by making a call on the 
Blob/Clob object. Since Oracle maps type-name "BLOB" to 
java.sql.Type.OTHER, it would not use that 2-stage mechanism, and thus 
would not operate as a "BLOB" should, even though it has that name. 
(Actually, this surprises the heck out of me since I had the impression 
from some info from Colin that Oracle had real BLOB/CLOB types, not 
something fudged. By the way, every DBMS I've been able to get running 
on my machine uses some funky non-standard BLOB/CLOB mechanism while 
calling the types "BLOB" and "CLOB". Postgess actually stores them as 
LONGVARBINARY objects!) 
  
So you see my problem is how to handle things consistantly from DBMS to 
DBMS when the DMBS manufacturers haven't agreed on how to handle things 
consistantly. I really think that relying on the name would get us in 
trouble (witness the "BLOB/CLOB" case). I haven't thought about the 
DBMS-specific plug-in approach, but that might work. Any other good ideas? 
  
Glenn 
  
> 
> 
> Maury... 
  
  
------------------------------------------------------- 
This SF.net email is sponsored by: VM Ware 
With VMware you can run multiple operating systems on a single machine. 
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the 
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 
_______________________________________________ 
Squirrel-sql-develop mailing list 
Squ...@li... 
https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop