column name is a reserved keyword

Hi, I am changing an existing application to use OJB. The problem that I ran into is that some of the column names are reserved keywords, e.g. 'print'. I need to configure OJB to put all column names in brackets, e.g. [print], when retrieving values from the database. Otherwise, SQL Server throw

Re: [OTM] can not delete from dependent collection

Hi Joerg, I have fixed this issue too. You are extremely productive tester! :-) Oleg On Tuesday 02 March 2004 16:39, Joerg Heinicke wrote: > My persons have a name, changing this one and making this change persistent > does not update the database. After makePersistent(debitor) it contains > aga

Re: Extent problem with ODMG

This did indeed solve the problem. In summary, repository.xml has: - Foreign key field defined in subclasses only - Relationship defined in subclasses and in superclass And in Java the relationship accessors are defined in the superclass only. I didn't even know that one could put field

Re: Extent problem with ODMG

hi, you'll have to define the relationship to D in the abstract S as well as in the concrete B and C. it has to be defined in S because when navigation from A the descriptor of class S is used to resolve the relationship. i tried this meaningless query : Criteria crit = new Criteria(); crit.ad

Re: ODMG UPDATE TOO FAST: DB not updated from jboss(daemon) and tomcat

Dear Thomas, Thanks for your response. The DB does get updated by the JBOSS daemon. However, when the OJB implementation is accessed directly by tomcat running in the same JBOSS instance, it does not update the database. You are right that the corresponding sql update does not happen(no corre

Referencing tables not in return object

I am not sure how to do something and have tried a couple of approaches without success. I could use some help. My problem comes down to the idea that I want to return a mapped object but based on a complex query that gets messed up due to the way OJB uses foreign keys. Is there a way to do

Re: Extent problem with ODMG

hi charles, steve, i do not think that my fix is related to this problem. i propose to move the definition of the relationship to the concrete classes. jakob Charles Anthony wrote: Hi, I have a hunch - quite possibly misplaced - that this may have something to do the bug I reported in the thh

Re: JOIN and aliases...is this a bug?

hi alessandro, according to your repository db.DBAttribute contains a field called 'nname' there's no field called 'name'. so you can either change your repository or adapt your query: Criteria c = new Criteria(); c.addEqualsTo("attributes.nname", "Ale"); Query q = QueryFactory.newQuery(DB

RE: Extent problem with ODMG

Have you tried duplicating the collection descriptor in the repository for each extent? I don't believe that OJB supports collection or reference descriptor inheritance. Wally -Original Message- From: Steve Clark [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 11:24 AM To: OJB

RE: Extent problem with ODMG

Charles, Thanks for the suggestion. I have tried CVS HEAD and I still get the same incorrect behavior. I'm still unclear whether OJB even *expects* to get this query right, because it doesn't know that 'com' is actually a property of the abstract superclass. That is, when it follows the 'abs' r

Re: Re: delete relation in indirection-table

As far as I remember, this behaviour was changed since 0.96 or 0.97 - I'm not sure. Of course, a DTD comment alerting that RemovalAwareCollection is default is very welcome. And changes in DOCs, specially relative to M:N mapping, recommending to not use default value for collection-class IMHO is

Re: delete relation in indirection-table

Olivier NOUGUIER wrote: Hi all, Nope I didn't found any thing on the subject, I found this behaviour while debugging ojb ( thank to eclipse ). And then reading comment in example bundled with ojb. Same behaviour with all ( I played with ) layer ( odmg, PB ). It's should be documented AND speci

Re: Re: delete relation in indirection-table

Hi all, Nope I didn't found any thing on the subject, I found this behaviour while debugging ojb ( thank to eclipse ). And then reading comment in example bundled with ojb. Same behaviour with all ( I played with ) layer ( odmg, PB ). It's should be documented AND specified that default collec

RE: [OTM] bi-directional 1:n not working (still not working)

Bad day for attachments. This is correct second test case, ignore TestRegistryDirectPart2. Regards, ** | Scott T Weaver | | <[EMAIL PROTECTED]>| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | *===

RE: [OTM] bi-directional 1:n not working (still not working)

I am now using tandem test cases to simulate the shutdown of the system and a restart, i.e. no cached items. I run the identical fetching tests in the second test case as I do in the first (only the first case creates the test data). Everything works in the first case but after restart the second

Sorry error to forward message !

Reda Benzair wrote: suite à une discution dans OJB forum il y un autil tres interessant Open Source pour la suppervission au niveau du JDBC interessant de voir ça si en peut l'integer chez nous http://www.irongrid.com/catalog/product_info.php?products_id=32 Charles Anthony wrote: Hi, I'm not su

un outil interessant pour la supervission des statment JDBC

suite à une discution dans OJB forum il y un autil tres interessant Open Source pour la suppervission au niveau du JDBC interessant de voir ça si en peut l'integer chez nous http://www.irongrid.com/catalog/product_info.php?products_id=32 Charles Anthony wrote: Hi, I'm not sure if you are aware

Re: delete relation in indirection-table

Hi all, is this behaviour documented? regards, Armin Klaus Ripplinger wrote: Hi Olivier, Hi Edson, using MangeableVector solved the problem! thanks a lot! Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional comma

Re: delete relation in indirection-table

Hi Olivier, Hi Edson, using MangeableVector solved the problem! thanks a lot! Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]