• 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: ec.saveChages gives null exception (didn't before) SOLVED
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ec.saveChages gives null exception (didn't before) SOLVED


  • Subject: Re: ec.saveChages gives null exception (didn't before) SOLVED
  • From: Drew Thoeni <email@hidden>
  • Date: Tue, 8 Mar 2005 20:58:43 -0500

As I was typing the below, making sure I'd covered all the bases, I went to verify that each of the things you all had pointed out were actually working. Pierre wins the prize!

This table is large so some columns were beyond the scroll window and one of them was, in fact, missing the external type (must have hit the delete key at the wrong time). Since I kept looking at the PK column, I didn't see this. Simple enough. But hard to find.

I'm leaving the below text in hope that the thread will help someone else in the future. Back to coding!

regards and thanks again.

Drew

---
First, thank you all for the tips. I'm learning a lot because of this particular problem.


Now, more news...

I've done some more experimenting and some very odd things are occurring. The facts:

1) This behavior only happens on inserts and updates to this table (classroom)
2) I was able to, not sure how, coax it into adding a single record. The odd part, very odd, was the PK assigned by Frontbase was 2147483647
3) This number, interestingly is 1 + the precision limit of the database.
4) Subsequent inserts fail, not at the insert statement, but now at the "SELECT UNIQUE" statement, which is trying to obtain a PK from Frontbase
5) I have reset the PK generator in Frontbase and tested the "SELECT UNIQUE" statement in the database. It works fine, both before and after resetting the PK.
6) All columns have ...ooops... HERE THE PROBLEM.


So, given this, it appears there is some failure in EOModel to accurately request (or receive) the PK for this table only.


On Mar 8, 2005, at 1:14 PM, Chuck Hill wrote:


On Mar 8, 2005, at 3:52 AM, Drew Thoeni wrote:

I dropped the jdbc2info and allowed EOM to recreate it. Still, the problem persists. I also posted again in response to an off list response I got regarding exposure of the PK.

I've traced the SQL and have a related question. Just prior to EOF asking the database for the primary key (to prepare for an insert) EOF does a call to the database selecting *every* record in the table about to be updated. This is trivial for a test database, but in production, if you had, say, 100,000 records, it seems like this is unneeded and burdensome behavior from EOF.

Why does EOF do this and should it be stopped?

It sounds like some form of pessimistic locking. What does your JDBC URL look like? Check the docs for the FB JDBC driver. You want to have this on the end of the JDBC URL:
/isolation=read_committed/locking=optimistic


OK, that said, the JDBC URL is probably not the cause of the select. Does it do this for every table, or just some? It is certainly not _supposed_ to be doing this.


Chuck


On Mar 7, 2005, at 11:28 PM, Chuck Hill wrote:


On Mar 7, 2005, at 5:46 PM, Drew Thoeni wrote:

I've researched Chuck's idea (below) and EOModeler jdbc2info says I'm using the right info (FrontBase). FYI, I'm not planning on changing databases frequently.

I also followed up on Arturo's suggestion and my foreign keys are marked as "NO" under "Deferrable" in "Check" in the table definition. So, a couple of questions:

While this is a good idea, I doubt it is the cause of the exception message below. The message below suggests that the error in either in the jdbc2info or in how you have modeled an attribute. Double check your model. Then check it again.


1) Can the "deferred" value be set in EOModeler and passed to the DB via the SQL command in EOModeler?

No, this is not a function of EOModeler.


2) If not, (and this is really a Frontbase question) it appears you can't modify this in Frontbase once it is set (must delete referential rule and readd). Is this correct. Frontbase user's guide is silent on this matter.

I believe that is correct. That is what I have always done in any case.

Chuck


Regards,

Drew

On Mar 7, 2005, at 12:37 PM, Chuck Hill wrote:

It is more likely what you have not done. When you connect to a database in EOModeler, it caches some database specific information to the connection dictionary under the jdbc2info key. If you later change databases (as I recall you have) and don't use EOModeler to connect to the new database, this jdbc2info will still be for the old database. I'm not 100% sure that connecting to the new DB will update this, it's not something I do frequently.

If you inspect the root node in the EOModel you should see this jdbc2info key. Delete it and save the model. If you want you can then connect to the new database and save the model, or EOF can regenerate this information from the database each time it is run. If you are going to switch back and forth a lot, I would try to avoid saving this information in the model. Note that if it is not in the model, EOF will keep two connections to the database open, one for data and one for this information. In most cases this does not matter, but it will in you are in a environment where the DB license is on a per connection basis.

Chuck

On Mar 6, 2005, at 8:08 PM, Drew Thoeni wrote:

For quite some time, this method, and all others that save to the Class table (like a classroom, not an object definition) worked fine. I've looked at the SQL that is being generated and it appears fine. There is only one not-null column in the table (the key) and the failures are on updates to an existing record. Clearly, something is null that should not be. And, it seems it's a result of something I've done. But I've spent about an hour tinkering with this and (probably in 10 minutes) reached my level of expertise.

Can anyone suggest what I might check into regarding this exception?


[2005-03-06 22:49:59 EST] <main> Waiting for requests...
[2005-03-06 22:58:35 EST] <WorkerThread8> java.lang.NullPointerException
at com.webobjects.jdbcadaptor.JDBCAdaptor.isValidQualifierType(JDBCAd aptor.java:659)
at com.webobjects.eoaccess.EODatabaseContext.isValidQualifierTypeForA ttribute(EODatabaseContext.java:5146)
at com.webobjects.eoaccess.EODatabaseContext.lockingNonQualifiableAtt ributes(EODatabaseContext.java:5160)
at com.webobjects.eoaccess.EODatabaseContext.createAdaptorOperationsF orDatabaseOperationAttributes(EODatabaseContext.java:5346)
at com.webobjects.eoaccess.EODatabaseContext.createAdaptorOperationsF orDatabaseOperation(EODatabaseContext.java:5520)
at com.webobjects.eoaccess.EODatabaseContext.performChanges(EODatabas eContext.java:6337)
at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEdi tingContext(EOObjectStoreCoordinator.java:411)
at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingCon text.java:3148)
at ClassAdmin.saveClass(ClassAdmin.java:63)

--
Practical WebObjects - a book for intermediate WebObjects developers who want to increase their overall knowledge of WebObjects, or those who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects







--
Practical WebObjects - a book for intermediate WebObjects developers who want to increase their overall knowledge of WebObjects, or those who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects







--
Practical WebObjects - a book for intermediate WebObjects developers who want to increase their overall knowledge of WebObjects, or those who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects






_______________________________________________ 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: 
 >ec.saveChages gives null exception (didn't before) (From: Drew Thoeni <email@hidden>)
 >Re: ec.saveChages gives null exception (didn't before) (From: Chuck Hill <email@hidden>)
 >Re: ec.saveChages gives null exception (didn't before) (From: Drew Thoeni <email@hidden>)
 >Re: ec.saveChages gives null exception (didn't before) (From: Chuck Hill <email@hidden>)
 >Re: ec.saveChages gives null exception (didn't before) (From: Drew Thoeni <email@hidden>)
 >Re: ec.saveChages gives null exception (didn't before) (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Jar Questions
  • Next by Date: Re: CocoaEOApplication
  • Previous by thread: Re: ec.saveChages gives null exception (didn't before)
  • Next by thread: Re: ec.saveChages gives null exception (didn't before)
  • Index(es):
    • Date
    • Thread