Adam Glazier

I have successfully created and changed tables with FLOATS as values, but can't figure out the correct syntax for strings.

update CREATE TABLE Sound0( fName CHAR(64) )

update INSERT INTO Sound0(fName) VALUES ('sound_0.wav')

Am I doing something wrong or do I have to get the value differently? ...sql_type_1 should read sound_0.wav

// Create the table
update CREATE TABLE Sound0( fName CHAR(64) )

// Submit data to table
update INSERT INTO Sound0(fName) VALUES ('sound_0.wav')

// Get table data
query SELECT * FROM Sound0

problem-getting-sting-value-from-net-loadbang-sql

If you're selecting *, then you're pulling a whole record, not a 

specific field, so MySQL probably quite legitimately treats that as a 

different type (viz., a record containing char(64)).

> I have successfully created and changed tables with FLOATS as values,

> but can't figure out the correct syntax for strings.

> // Create the table update CREATE TABLE Sound0( fName CHAR(64) )

> // Submit data to table update INSERT INTO Sound0(fName) VALUES

> // Get table data query SELECT * FROM Sound0

> Am I doing something wrong or do I have to get the value differently?

If you're selecting *, then you're pulling a whole record, not a 
specific field, so MySQL probably quite legitimately treats that as a 
different type (viz., a record containing char(64)).

.Adam Glazier wrote:
> I have successfully created and changed tables with FLOATS as values,
> but can't figure out the correct syntax for strings.
>
>
> // Create the table update CREATE TABLE Sound0( fName CHAR(64) )
>
>
> // Submit data to table update INSERT INTO Sound0(fName) VALUES
> ('sound_0.wav')
>
> // Get table data query SELECT * FROM Sound0
>
> // this returns: sql_type_1
>
>
> Am I doing something wrong or do I have to get the value differently?
> ...sql_type_1 should read sound_0.wav


I tried that as well ( eg: query SELECT fName FROM Sound0 ) and get the same result ( sql_type_1 ).

When I query entries that are FLOATs either way, I get the actual number...It's odd that CHARs act differently.

On 26 May 2007, at 23:20, Owen Green wrote:

> If you're selecting *, then you're pulling a whole record, not a 

> specific field, so MySQL probably quite legitimately treats that as 

> a different type (viz., a record containing char(64)).

The "SELECT *" should behave properly, and give you a list of Max 

symbols or values. (I suspect I actually collapse a list of length 

one to an atom - I'd need to check the code.)

The problem with the original posting is almost certainly the "CHAR 

(64)" - I didn't see why developers would want to work with limited- 

size strings so I didn't put in support for CHAR (SQL type 1). Is 

there a reason why you don't want to use VARCHAR?

nick rothwell -- composition, systems, performance -- 

> If you're selecting *, then you're pulling a whole record, not a  
> specific field, so MySQL probably quite legitimately treats that as  
> a different type (viz., a record containing char(64)).

The "SELECT *" should behave properly, and give you a list of Max  
symbols or values. (I suspect I actually collapse a list of length  
one to an atom - I'd need to check the code.)

The problem with the original posting is almost certainly the "CHAR 
(64)" - I didn't see why developers would want to work with limited- 
size strings so I didn't put in support for CHAR (SQL type 1). Is  
there a reason why you don't want to use VARCHAR?

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


Thanks for the tip, it works! I don't know why I would ever need a fixed string length either :)

Since CHAR is not supported...are there any other features of SQL that are not supported...or perhaps some documentation somewhere that I missed?

Thanks for the tip, it works!  I don't know why I would ever need a fixed string length either :)

Since CHAR is not supported...are there any other features of SQL that are not supported...or perhaps some documentation somewhere that I missed?


On 27 May 2007, at 17:06, Adam Glazier wrote:

> Since CHAR is not supported...are there any other features of SQL 

> that are not supported...or perhaps some documentation somewhere 

There are about 30 distinct SQL types exposed at the Java level, from 

the obvious to the obscure ("DATALINK" anyone?). Not all of these 

make sense in the Max world, and I'd also expect different databases 

to use them differently. For the record, the ones I'm currently 

I can add others, but since I'm supporting three databases (HSQL, 

Derby, MySQL) I can see the potential for various nonworking or 

problematic combinations to be quite large.

> Since CHAR is not supported...are there any other features of SQL  
> that are not supported...or perhaps some documentation somewhere  
> that I missed?

There are about 30 distinct SQL types exposed at the Java level, from  
the obvious to the obscure ("DATALINK" anyone?). Not all of these  
make sense in the Max world, and I'd also expect different databases  
to use them differently. For the record, the ones I'm currently  
supporting are

	INTEGER, BIGINTEGER (-> int)
	FLOAT (-> float)
	VARCHAR, LONGVARCHAR (-> symbol)

I can add others, but since I'm supporting three databases (HSQL,  
Derby, MySQL) I can see the potential for various nonworking or  
problematic combinations to be quite large.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.loadbang.net


Problem getting sting value from net.loadbang-SQL