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]

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

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

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

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

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

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: JOIN and aliases...is this a bug?

hi alessandro, according to your repository db.DBAttribute contains a field called 'nname' field-descriptor name=nname column=NAME primarykey=true jdbc-type=VARCHAR / there's no field called 'name'. so you can either change your repository or adapt your query:

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

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

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

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();

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

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 again

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