Problem with special characters in entity type="very-long"

[Carl Gleisner]

Storing Swedish special characters 'åäö' using type="very-long" returns the following error

ERROR: Could not complete the create a Example [file:/E:/ofbiz/framework/example/script/org/ofbiz/example/example/ExampleServices.xml#createExample] process [problem creating the newEntity value: Exception while inserting the following entity: [GenericEntity:Example][comments,åäö(java.lang.String)][createdStamp,2007-04-30 11:49:41.996(java.sql.Timestamp)][createdTxStamp,2007-04-30 11:49:41.66(java.sql.Timestamp)][description,åäö(java.lang.String)][exampleDate,2007-04-30 11:49:27.955(java.sql.Timestamp)][exampleId,10000(java.lang.String)][exampleName,åäö(java.lang.String)][exampleSize,12(java.lang.Long)][exampleTypeId,CONTRIVED(java.lang.String)][lastUpdatedStamp,2007-04-30 11:49:41.996(java.sql.Timestamp)][lastUpdatedTxStamp,2007-04-30 11:49:41.66(java.sql.Timestamp)][longDescription,åäö(java.lang.String)][statusId,EXST_IN_DESIGN(java.lang.String)] (while inserting: [GenericEntity:Example][comments,åäö(java.lang.String)][createdStamp,2007-04-30 11:49:41.996(java.sql.Timestamp)][createdTxStamp,2007-04-30 11:49:41.66(java.sql.Timestamp)][description,åäö(java.lang.String)][exampleDate,2007-04-30 11:49:27.955(java.sql.Timestamp)][exampleId,10000(java.lang.String)][exampleName,åäö(java.lang.String)][exampleSize,12(java.lang.Long)][exampleTypeId,CONTRIVED(java.lang.String)][lastUpdatedStamp,2007-04-30 11:49:41.996(java.sql.Timestamp)][lastUpdatedTxStamp,2007-04-30 11:49:41.66(java.sql.Timestamp)][longDescription,åäö(java.lang.String)][statusId,EXST_IN_DESIGN(java.lang.String)] (SQL Exception while executing the following:INSERT INTO EXAMPLE (EXAMPLE_ID, EXAMPLE_TYPE_ID, STATUS_ID, EXAMPLE_NAME, DESCRIPTION, LONG_DESCRIPTION, COMMENTS, EXAMPLE_SIZE, EXAMPLE_DATE, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (Data truncation: Data too long for column 'LONG_DESCRIPTION' at row 1)))]

I'm using MySQL 5.0 and it is set to use UTF8. I think it is rooted in the database because I tried to add them using the mysql query browser and I got the same message. Do you have any experience with this? Does it work in your DB?

Carl

[Walter Vaughan]

carlj wrote:

> I'm using MySQL 5.0 and it is set to use UTF8. I think it is rooted in the
> database because I tried to add them using the mysql query browser and I got
> the same message. Do you have any experience with this? Does it work in your
> DB?

I can insert those characters using pgAdminIII into a long description field, as
well as at https://demo.hotwaxmedia.com/catalog/control/updateProductContent 
with no problem. PostgreSQL as configured by ofBiz has no problems with your
characters.

We learned the hard way that mySQL is probably not the best solution for an ERP.
Wierd stuff just happens that really isn't the end of the world for a normal
LAMP application using MySQL is a deal breaker when you are using in an
accounting backbone function.

MySQL is 99-44/100% good with ofBiz. It's that .56% that will drive you to
wonder,  "why do I think MySQL would be a better solution when I don't think any
of the core committers on this project work with mySQL as their primary
development environment?" [0]

--
Walter
[0] If I am wrong here, please speak up, but this is the impression I have.

[Carl Gleisner]

Walter Vaughan wrote

carlj wrote:

> I'm using MySQL 5.0 and it is set to use UTF8. I think it is rooted in the
> database because I tried to add them using the mysql query browser and I got
> the same message. Do you have any experience with this? Does it work in your
> DB?

I can insert those characters using pgAdminIII into a long description field, as
well as at https://demo.hotwaxmedia.com/catalog/control/updateProductContent 
with no problem. PostgreSQL as configured by ofBiz has no problems with your
characters.

We learned the hard way that mySQL is probably not the best solution for an ERP.
Wierd stuff just happens that really isn't the end of the world for a normal
LAMP application using MySQL is a deal breaker when you are using in an
accounting backbone function.

MySQL is 99-44/100% good with ofBiz. It's that .56% that will drive you to
wonder,  "why do I think MySQL would be a better solution when I don't think any
of the core committers on this project work with mySQL as their primary
development environment?" [0]

--
Walter
[0] If I am wrong here, please speak up, but this is the impression I have.

I don't have any special reason to use MySQL so I'll just migrate to postgre. Thank you so much for the input!

Carl

[David E Jones]

Just a note for mail archive reasons: this is a known issue with  
MySQL and in general the way multi-byte character sets are done in  
MySQL is baffling and makes it impossible to use. Instead of dealing  
with multi-byte characters in physical storage so that a 255  
character string is stored as 765 characters, it handles it higher up  
so that a physical 255 character column is effectively 85 UTF-8  
characters which causes obvious problems for an application like  
OFBiz, and I imagine so many other applications...

-David


On Apr 30, 2007, at 8:24 AM, carlj wrote:

>
>
> Walter Vaughan wrote:
>>
>> carlj wrote:
>>
>>> I'm using MySQL 5.0 and it is set to use UTF8. I think it is  
>>> rooted in
>>> the
>>> database because I tried to add them using the mysql query  
>>> browser and I
>>> got
>>> the same message. Do you have any experience with this? Does it  
>>> work in
>>> your
>>> DB?
>>
>> I can insert those characters using pgAdminIII into a long  
>> description
>> field, as
>> well as at
>> https://demo.hotwaxmedia.com/catalog/control/updateProductContent
>> with no problem. PostgreSQL as configured by ofBiz has no problems  
>> with
>> your
>> characters.
>>
>> We learned the hard way that mySQL is probably not the best  
>> solution for
>> an ERP.
>> Wierd stuff just happens that really isn't the end of the world for a
>> normal
>> LAMP application using MySQL is a deal breaker when you are using  
>> in an
>> accounting backbone function.
>>
>> MySQL is 99-44/100% good with ofBiz. It's that .56% that will  
>> drive you to
>> wonder,  "why do I think MySQL would be a better solution when I  
>> don't
>> think any
>> of the core committers on this project work with mySQL as their  
>> primary
>> development environment?" [0]
>>
>> --
>> Walter
>> [0] If I am wrong here, please speak up, but this is the impression I
>> have.
>>
>>
>
> I don't have any special reason to use MySQL so I'll just migrate to
> postgre. Thank you so much for the input!
>
> Carl
> --
> View this message in context: http://www.nabble.com/Problem-with- 
> special-characters-in-entity-type%3D%22very-long%22-
> tf3669303.html#a10254246
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>