-----Original Message-----

From: dabo-users-bounces@leafe.com [mailto:dabo-users-bounces@leafe.com] On

Behalf Of Ed Leafe

Sent: Tuesday, November 11, 2008 5:57 PM

To: Dabo Users list

Subject: Re: [dabo-users] Adding data to bizobj programmatically

On Nov 11, 2008, at 4:34 PM, <lalong1@charter.net> <lalong1@charter.net>

wrote:

> We would like to append a record into the primary biz obj from a

> dataset gathered from another bizobj.

>

> We are trying the following

>

> myrec=bizobj.getDataSet()

> self.Form.PrimaryBizobj._CurrentCursor._records += myrec

>

> But when we do, the bizobj validate record nor any other methods seem

> to fire when saving.

>

> Are we going about this the wrong way?

The naming standard in Python says that any attribute or method that

begins with '_' means that it is an internal implementation, and should not

be accessed outside of the class. While you've changed the recordset, you've

bypassed several internal details that keep track of the state of the

various records.

So let me understand what you need to do, and perhaps we could add a

simple way to do it to the framework. You want to pass a dataset to a

bizobj, and have it add that dataset to its current dataset? Seems simple

enough, but a couple of questions: what should happen if the columns are not

the same? What about if a PK is duplicated? Should the validation fire at

the time they are added, or when they are saved?

What about field-level validation? Can we assume that these records are all

new, i.e., all INSERTs into the database?

-- Ed Leafe

Ed,

Our goal is to "nearly" duplicate a record with only a field or two

difference without having to go thru a looping procedure.

I understand about the "_" objects. My try was based on the cursormixin's

new() method code and it seemed simple enough to duplicate. I then tried

looping thru the data using the getFieldNames.

>def getFieldNames(self):

> """Returns a tuple of all the field names in the cursor."""

However, getFieldNames returns all the fields from the backend and not the

fields in my bizObj so it blew up when it hit a field not defined in the

bizobj.

The pkid is a non-updatable field in the bizobj so it's a "don't care".

Validation behaviour remains unchanged. Yes, all are new. Columns must be

assumed to be a subset of the target, otherwise ignored (in our case this

won't happen)

Thanks,

Larry

[excessive quoting removed by server]