Forums > Java

Problem getting sting value from net.loadbang-SQL

May 26, 2007 | 9:01 pm

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

~adam


May 26, 2007 | 10:20 pm

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)).

Try making your query more specific:

SELECT fName FROM Sound0


Owen

.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


May 27, 2007 | 1:07 am

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.


May 27, 2007 | 9:09 am

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?

– N.

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


May 27, 2007 | 4:06 pm

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?


May 27, 2007 | 6:17 pm

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
> 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.

– N.

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


May 28, 2007 | 3:17 am

Thanks for the tip!!!!! :)


Viewing 7 posts - 1 through 7 (of 7 total)