• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Strange behavior of Derby database. SQL generation (SOLVED) (New issue: 24 bytes auto generated primary keys)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange behavior of Derby database. SQL generation (SOLVED) (New issue: 24 bytes auto generated primary keys)


  • Subject: Re: Strange behavior of Derby database. SQL generation (SOLVED) (New issue: 24 bytes auto generated primary keys)
  • From: Sergio Sánchez Maffet <email@hidden>
  • Date: Tue, 5 Feb 2008 21:49:47 +0100

Pierre,

I will file a bug.

There is another issue regarding 24 bytes auto generated primary keys. The type "CHAR FOR BIT DATA" is not recognized generating create table statements from WOLips Entity Modeler and CHAR does not work at all with NSData as an internal type. Seems that the NSData internal type is initialized with a stream that is not present when you use CHAR external data types.

Workaround: Use BLOB data type for 24 byte primary keys. But this is surely very slow...

I will also file a bug.

Cheers,
Sergio



On 05.02.2008, at 21:32, Mr. Pierre Frisch wrote:

I would still log a bug, please. This may be something we can fix in the plug-in.

Pierre
--
Pierre Frisch
email@hidden


On Feb 5, 2008, at 12:18, Sergio Sánchez Maffet wrote:

After intensiv reading of the derby docs I found the reason. It happens because derby alway uppercases all unquoted identifiers. The SQL generation in WOLips puts quotes around the identifiers, turning on case sensitivity in derby during creation of the tables. The generation of SQL in SQLExpression later accessing the database uses unquoted identifiers. They are uppercased by derby and checked against the case-sensitiv stored ones, which where in my case lowercase ones. Tricky.

The workaround is simple: Use always uppercase identifiers in your model file.


On 05.02.2008, at 20:16, Sergio Sánchez Maffet wrote:

The table name in the log submitted in my prior post should be TESTA and not CONTENT. This is only a copy paste failure... and does not mean, that a have misspelled the table name! The problem is still there...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@codeon.de


This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden



_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Strange behavior of Derby database. SQL generation (From: Sergio Sánchez Maffet <email@hidden>)
 >Re: Strange behavior of Derby database. SQL generation (From: David Avendasora <email@hidden>)
 >Re: Strange behavior of Derby database. SQL generation (From: Sergio Sánchez Maffet <email@hidden>)
 >Re: Strange behavior of Derby database. SQL generation (From: Sergio Sánchez Maffet <email@hidden>)
 >Re: Strange behavior of Derby database. SQL generation (SOLVED) (From: Sergio Sánchez Maffet <email@hidden>)
 >Re: Strange behavior of Derby database. SQL generation (SOLVED) (From: "Mr. Pierre Frisch" <email@hidden>)

  • Prev by Date: Re: Strange behavior of Derby database. SQL generation (SOLVED)
  • Next by Date: Re: Problems with Stale Data
  • Previous by thread: Re: Strange behavior of Derby database. SQL generation (SOLVED)
  • Next by thread: Re: Problems with Stale Data
  • Index(es):
    • Date
    • Thread