gnue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUe] Inverse Master/Detail relations


From: James Thompson
Subject: Re: [GNUe] Inverse Master/Detail relations
Date: Tue, 16 Aug 2005 22:21:28 -0500
User-agent: KMail/1.8

> Thank you for your replay. With your suggestion I can insert new
> records now! When I tryed to set the M/D things up, I got some strange
> problems, but I think I did something wrong that time. My problem now
> is that I had to delete the referencing constrain on the column, to
> allaw the master record to be stored before the detail record.
>
> Can I execute the insertion of the detail record from the trigger, so
> that the referencing constrain can be left in the database?

That should work I think.  If you have to you can setup a detail block that is 
associated with a datasource that isn't tied to a database table.  Then upon 
commit (maybe as part of a pre-insert trigger on the master) you could 
iterate through the detail records, give them IDs, and then use a second 
datasource to insert the records.  I do something similar in my shipping app.  
Here is a bit of that logic

            for record in blkItem:
              serialNo = str(blkItem.fldSerial_no.get()).strip()
              
             #  Cut a bunch of misc junk here to save space in email :)

              # Add items to the packing slip
              psItemRs = dtsPackslip_items.createResultSet(query=False)
              record = psItemRs.insertRecord()
              record['packslip_id'] = packslipId
              record['item_id'] = result['item_id']
              record['serial_no'] = serialNo
              psItemRs.post()
              form.commit()

The one big difference is that in my case none of the blocks in my form that 
users interact with are tied to tables.  I hide menu and toolbars, put a 
clear and a commit button on the form.  The commit button builds the records 
I need and inserts them via datasources like above.  So in your case I'm not 
sure what effect the form.commit() call will have.

> Another question about dropdown boxes. Can I set up a dropdown or a
> list box which doesn't offer the a blank entry as an option?

I don't think you can not have the blank.  But on your field you can set 
something like (from zipcode.gfd sample)

<field name="state" default="KS" field="state"
           fk_description="description" fk_key="state" fk_source="validator"    
   
           required="Y">

which would set the field to display Kansas and you couldn't store a null 
value.  

I know that support a non blank value on dropdowns wouldn't be too hard to add 
to forms.  I'm not sure how much work would be involved in dealing w/ your 
reverse master/detail relationship better in GNUe.  When a bit of time is 
freed up maybe we can look at making what you want easier to do.

Take Care,
james




reply via email to

[Prev in Thread] Current Thread [Next in Thread]