Manually entered PK: records not saved

[Sibylle Koczian-2]

Hello,

trying out a dTextBox with decimal values (which works without problems, thank
you for the quick answers!) I hit a new snag:

SQLite database, one table, only the three fields mentioned in the UserSQL.
The primary key in this case is of type CHAR(3) and is filled in manually in
the application. No autoincrement, no setting by trigger. Application with
three dTextBox instances for these three fields and buttons for navigating,
New, Save, Cancel, Exit.

1. self.DefaultValues = None:

class BizNum(dabo.biz.dBizobj):
        def initProperties(self):
                self.DataSource = "numtest"
                self.KeyField = "idn"
                self.UserSQL = """SELECT idn, amount, remark FROM numtest"""
                self.DefaultValues = None
                self.DataStructure = (("idn", "C", True, "numtest", "idn"),
                ("amount", "N", False, "numtest", "amount"),
                ("remark", "C", False, "numtest", "remark"))

Button "New" fills in the idn field with "-1-", the two other fields
with "<None>". I overwrite the "-1-" with a unique new value for the PK and
enter a number into the "amount" field. Then I press "Save" and get this:

"Save Failed:

no such column: dabo-tmpKeyField
SQL: update "numtest" set "idn" = 'AC1', "amount" = 34.50, "remark" =
NULL, "dabo-tmpKeyField" = NULL where "idn"='-1-dabotmp' "

2. Nothing set for self.DefaultValues:

Button "New" fills the idn field with "-1-" as before, the "amount" field
with "0.00", the "remark" field stays empty. I enter values, press "Save". No
error message, "Changes to all records saved" in the status line. I navigate
in the data, the last record is the newly entered one. I close my application
and start the sqlite command line client: no trace of the new record.

3. self.DefaultValues = {"idn": "ZZZ", "remark": None}:

Now the idn field of a new record is filled with "ZZZ" If I change that value
(which would be the normal procedure), the result is exactly the same as
before (No. 2). If I let it unchanged (one record with primary key ZZZ would
be possible), I get:

"Save Failed:

numtest.idn may not be NULL
SQL: insert into "numtest" ("amount", "remark") values (8999.33, NULL) "

4. self.AutoPopulatePK = false:

The idn field of a new record is now empty, but still "Changes to all records
saved" and no new record in the database when I view it with the sqlite
command line client (or if I close and restart my dabo application).

I can't find any way to get new records into the database. This seems to be a
problem with manually entered primary keys, it doesn't happen with
autoincrement PK fields. Will try this next with a Firebird database, because
I really need this with one of my Firebird databases.

What can I do?

Thank you,
Sibylle

--
Dr. Sibylle Koczian


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/200809221713.04482.Sibylle.Koczian@...

[Uwe Grauer-5]

Sibylle Koczian wrote:

> Hello,
>
> trying out a dTextBox with decimal values (which works without problems, thank
> you for the quick answers!) I hit a new snag:
>
> SQLite database, one table, only the three fields mentioned in the UserSQL.
> The primary key in this case is of type CHAR(3) and is filled in manually in
> the application. No autoincrement, no setting by trigger. Application with
> three dTextBox instances for these three fields and buttons for navigating,
> New, Save, Cancel, Exit.
>
> 1. self.DefaultValues = None:
>
> class BizNum(dabo.biz.dBizobj):
> def initProperties(self):
> self.DataSource = "numtest"
> self.KeyField = "idn"

Please tell us why you would want to have CHAR(3) as your PK.
I'm asking because i would use technical PKs whenever possible.
If you need CHAR(3) as a unique key for lookups, just add a CHAR(3)
field with a unique key constraint in addition to your technical PK of
type NUMERIC(18,0) which is a BIGINT for Firebird.

If you need this for an existing database, then we have to find out
why this doesn't work for you.

Uwe


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/48D7EF81.8010408@...

[Ed Leafe]

On Sep 22, 2008, at 2:18 PM, Uwe Grauer wrote:

> Please tell us why you would want to have CHAR(3) as your PK.
> I'm asking because i would use technical PKs whenever possible.
> If you need CHAR(3) as a unique key for lookups, just add a CHAR(3)
> field with a unique key constraint in addition to your technical PK of
> type NUMERIC(18,0) which is a BIGINT for Firebird.

        I don't believe that the question was one seeking information about  
database design.

        No matter what the type/size of the PK selected, there should be  
*some* way to enable manually entering and saving them, no matter how  
wise or unwise that practice may be. I plan on looking into this code  
this evening.

-- Ed Leafe





_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/9C6D8605-08C4-4190-A810-ABB820ECF1BF@...

[Paul McNett]

Sibylle Koczian wrote:
> trying out a dTextBox with decimal values (which works without problems, thank
> you for the quick answers!) I hit a new snag:

Glad that part is working!

> SQLite database, one table, only the three fields mentioned in the UserSQL.
> The primary key in this case is of type CHAR(3) and is filled in manually in
> the application. No autoincrement, no setting by trigger.

See AutoPopulatePK property. In your case, I believe it needs to be set
to False.

http://paul.dabodev.com/doc/api/dabodoc/dabo.biz.dBizobj.dBizobj.html#Properties_AutoPopulatePK

> Application with
> three dTextBox instances for these three fields and buttons for navigating,
> New, Save, Cancel, Exit.
>
> 1. self.DefaultValues = None:
>
> class BizNum(dabo.biz.dBizobj):
> def initProperties(self):
> self.DataSource = "numtest"
> self.KeyField = "idn"
> self.UserSQL = """SELECT idn, amount, remark FROM numtest"""
> self.DefaultValues = None
> self.DataStructure = (("idn", "C", True, "numtest", "idn"),
> ("amount", "N", False, "numtest", "amount"),
> ("remark", "C", False, "numtest", "remark"))
>
> Button "New" fills in the idn field with "-1-", the two other fields
> with "<None>". I overwrite the "-1-" with a unique new value for the PK and
> enter a number into the "amount" field. Then I press "Save" and get this:

The whole value is '-1-dabotmp', which indicates to Dabo that this new
record still needs its real pk filled in, which will happen after the
save(): dabo will find out the pk value from the database backend and
fill it in for local use.

I think you are confusing Dabo by telling it that AutoPopulatePK is True
(because that's the default) but then giving the pk value manually.

> "Save Failed:
>
> no such column: dabo-tmpKeyField
> SQL: update "numtest" set "idn" = 'AC1', "amount" = 34.50, "remark" =
> NULL, "dabo-tmpKeyField" = NULL where "idn"='-1-dabotmp' "
>
> 2. Nothing set for self.DefaultValues:
>
> Button "New" fills the idn field with "-1-" as before, the "amount" field
> with "0.00", the "remark" field stays empty. I enter values, press "Save". No
> error message, "Changes to all records saved" in the status line. I navigate
> in the data, the last record is the newly entered one. I close my application
> and start the sqlite command line client: no trace of the new record.
>
> 3. self.DefaultValues = {"idn": "ZZZ", "remark": None}:
>
> Now the idn field of a new record is filled with "ZZZ" If I change that value
> (which would be the normal procedure), the result is exactly the same as
> before (No. 2). If I let it unchanged (one record with primary key ZZZ would
> be possible), I get:
>
> "Save Failed:
>
> numtest.idn may not be NULL
> SQL: insert into "numtest" ("amount", "remark") values (8999.33, NULL) "
>
> 4. self.AutoPopulatePK = false:
>
> The idn field of a new record is now empty, but still "Changes to all records
> saved" and no new record in the database when I view it with the sqlite
> command line client (or if I close and restart my dabo application).
>
> I can't find any way to get new records into the database. This seems to be a
> problem with manually entered primary keys, it doesn't happen with
> autoincrement PK fields. Will try this next with a Firebird database, because
> I really need this with one of my Firebird databases.
>
> What can I do?

Sorry, I missed at first reading that you are setting AutoPopulatePK to
False ('false' was just a typo, right?). I can tell you that my
sqlite-based application uses app-generated pk's and I don't recall
having such trouble.

Here's the relevant code from my base bizobj:

       1 # -*- coding: utf-8 -*-
       2
       3 from dabo.lib import getRandomUUID
       4 import dabo.lib.datanav2 as datanav
       5
       6 class Base(datanav.Bizobj):
       7
       8   def afterInit(self):
       9     self.super()
      10     self.setBaseSQL()
      11
      12
      13   def initProperties(self):
      14     self.AutoQuoteNames = False
      15     self.AutoPopulatePK = False
      16     self.DefaultValues["id"] = getRandomUUID
      17     self.SaveNewUnchanged = True

You can see that my default value for the pk field is the
dabo.lib.getRandomUUID function, but you could set it to any function
that returns a value.

The SaveNewUnchanged property could come into play when everything is
filled with default values: If you do a new() and a save() without
having changed anything different from what was set with DefaultValues,
the record won't be saved even though there wasn't any indication that
it didn't get saved. Therefore, I set this to True in my base bizobj
subclass.

Paul


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/48D7F608.4060603@...

[Paul McNett]

Ed Leafe wrote:
> No matter what the type/size of the PK selected, there should be  
> *some* way to enable manually entering and saving them, no matter how  
> wise or unwise that practice may be. I plan on looking into this code  
> this evening.

Just to reiterate: my app uses app-generated PK's with nothing special,
with sqlite, so I can confirm that it *can* work.

Paul


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/48D7F682.7060703@...

[Ed Leafe]

On Sep 22, 2008, at 10:13 AM, Sibylle Koczian wrote:

> I can't find any way to get new records into the database. This  
> seems to be a
> problem with manually entered primary keys, it doesn't happen with
> autoincrement PK fields. Will try this next with a Firebird  
> database, because
> I really need this with one of my Firebird databases.


        OK, I've had time to look this over, and you're close.

        As Paul mentioned, you need to set biz.AutoPopulatePK to False for  
Dabo to send PK values back to the server. But that should cause Dabo  
to send the full record, including the PK to the backend server.

        If you have the time to do some debugging, can you replace the  
__saverow() method of dCursorMixin with the version below, that  
includes some debug output? Run your app using scenario 4 in your  
original email, and when you try to save the record, there should be a  
couple of lines of debug output. Copy that output and paste it into a  
reply email. This may not give us the answer, but it will help point  
us in the right direction.


dCursorMixin.py, starting around line 1166:

        def __saverow(self, row):
                rec = self._records[row]
                recKey = self.pkExpression(rec)
                newrec = self._newRecords.has_key(recKey)
                newPKVal = None
                if newrec and self.AutoPopulatePK:
                        # Some backends do not provide a means to retrieve
                        # auto-generated PKs; for those, we need to create the
                        # PK before inserting the record so that we can pass it on
                        # to any linked child records. NOTE: if you are using
                        # compound PKs, this cannot be done.
                        newPKVal = self.pregenPK()
                        if newPKVal and not self._compoundKey:
                                self.setFieldVal(self.KeyField, newPKVal, row)

                print "newrec = ", newrec
                if newrec:
                        diff = self._getNewRecordDiff(row)
                else:
                        diff = self.getRecordStatus(row)
                print "diff = ", diff
                aq = self.AutoQuoteNames
                if diff:


-- Ed Leafe





_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/DBD3FA66-ED70-4F64-B8B0-84A42EBA7CE1@...

[Sibylle Koczian-2]

Hello,

many thanks for looking into this!

Am Dienstag, 23. September 2008 01:11:50 schrieb Ed Leafe:

> As Paul mentioned, you need to set biz.AutoPopulatePK to False for
> Dabo to send PK values back to the server. But that should cause Dabo
> to send the full record, including the PK to the backend server.
>
> If you have the time to do some debugging, can you replace the
> __saverow() method of dCursorMixin with the version below, that
> includes some debug output? Run your app using scenario 4 in your
> original email, and when you try to save the record, there should be a
> couple of lines of debug output. Copy that output and paste it into a
> reply email. This may not give us the answer, but it will help point
> us in the right direction.
>
>
> dCursorMixin.py, starting around line 1166:
>
> def __saverow(self, row):
> rec = self._records[row]
> recKey = self.pkExpression(rec)
> newrec = self._newRecords.has_key(recKey)
> newPKVal = None
> if newrec and self.AutoPopulatePK:
> # Some backends do not provide a means to retrieve
> # auto-generated PKs; for those, we need to create the
> # PK before inserting the record so that we can pass it on
> # to any linked child records. NOTE: if you are using
> # compound PKs, this cannot be done.
> newPKVal = self.pregenPK()
> if newPKVal and not self._compoundKey:
> self.setFieldVal(self.KeyField, newPKVal, row)
>
> print "newrec = ", newrec
> if newrec:
> diff = self._getNewRecordDiff(row)
> else:
> diff = self.getRecordStatus(row)
> print "diff = ", diff
> aq = self.AutoQuoteNames
> if diff:
>
>

Done.

Application started from a terminal. Starting it from the Dabo Editor may have
hidden error messages

1. Bizobj now looks like this, SQLite database unchanged:

class BizNum(dabo.biz.dBizobj):
        def initProperties(self):
                self.DataSource = "numtest"
                self.KeyField = "idn"
                self.AutoPopulatePK = False
                self.SaveNewUnchanged = True
                self.UserSQL = """SELECT idn, amount, remark FROM numtest"""
                self.DefaultValues = {"idn": "ZZZ", "remark": None}
                self.DataStructure = (("idn", "C", True, "numtest", "idn"),
                ("amount", "N", False, "numtest", "amount"),
                ("remark", "C", False, "numtest", "remark"))

Application started, new record entered (with manually changed PK),
button "save" pressed. Status line doesn't say anything about saved records,
only "Record 12/12 (EOF)" - this is one more than the table had before. Debug
output and traceback in the terminal:

newrec =  False
diff =  {'idn': (u'ZZZ', u'AC1'), 'amount': (Decimal("0.00"),
Decimal("75.60"))}

Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dControlMixin.py",
line 27, in _onWxHit
    self.raiseEvent(dEvents.Hit, evt, *args, **kwargs)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dPemMixin.py",
line 928, in raiseEvent
    super(dPemMixin, self).raiseEvent(eventClass, nativeEvent, *args,
**kwargs)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/lib/eventMixin.py",
line 92, in raiseEvent
    bindingFunction(event)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dForm.py",
line 682, in onSave
    def onSave(self, evt): self.save()
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dForm.py",
line 355, in save
    bizobj.saveAll()
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/biz/dBizobj.py",
line 337, in saveAll
    startTransaction=False)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/biz/dBizobj.py",
line 714, in scanChangedRows
    self._moveToRowNum(row)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/biz/dBizobj.py",
line 986, in _moveToRowNum
    self._CurrentCursor.moveToRowNum(rownum)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/db/dCursorMixin.py",
line 1589, in moveToRowNum
    raise dException.dException, _("Invalid row specified.")
dabo.dException.dException: Invalid row specified.

2. No change in the application, new record entered and saved without changing
the default PK. Status line "Changes to all records saved", output in the
terminal:

newrec =  True
diff =  {'idn': (None, u'ZZZ'), 'amount': (None, Decimal("56.77")), 'remark':
(None, None)}

Looking into the database afterwards shows the new record. But there is still
one abnormality: an "after insert" trigger in the database inserts text into
the "remark" field, if it is NULL. If I save the new record and navigate away
from it and back in my application, this added remark isn't there, the entry
field still shows "<None>". But after closing the application and opening the
SQLite command line client I can see the remark in the new record.

Of course this works exactly once, because the default PK is a fixed string.

3. No default PK:

...
self.SaveNewUnchanged = False
...
self.DefaultValues = None

PK entered manually (unique value). Status line as before, no traceback, debug
output in the terminal:

newrec =  False
diff =  {'idn': (u'', u'AC1'), 'amount': (None, Decimal("65.44"))}

Navigating in the application shows the new record (without the remark the
insert trigger should add), looking into the table afterwards doesn't show
it. This is the outcome I like least.

4. self.SaveNewUnchanged = True, no other changes:

Output in the terminal:

newrec =  False
diff =  {'idn': (u'', u'AC2'), 'amount': (None, Decimal("345.6"))}

Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dControlMixin.py",
line 27, in _onWxHit
    self.raiseEvent(dEvents.Hit, evt, *args, **kwargs)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dPemMixin.py",
line 928, in raiseEvent
    super(dPemMixin, self).raiseEvent(eventClass, nativeEvent, *args,
**kwargs)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/lib/eventMixin.py",
line 92, in raiseEvent
    bindingFunction(event)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dForm.py",
line 682, in onSave
    def onSave(self, evt): self.save()
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/ui/uiwx/dForm.py",
line 355, in save
    bizobj.saveAll()
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/biz/dBizobj.py",
line 337, in saveAll
    startTransaction=False)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/biz/dBizobj.py",
line 714, in scanChangedRows
    self._moveToRowNum(row)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/biz/dBizobj.py",
line 986, in _moveToRowNum
    self._CurrentCursor.moveToRowNum(rownum)
File "/usr/lib/python2.5/site-packages/Dabo-0.8.4-py2.5.egg/dabo/db/dCursorMixin.py",
line 1589, in moveToRowNum
    raise dException.dException, _("Invalid row specified.")
dabo.dException.dException: Invalid row specified.

To me this begins to look as if the primary key cannot be changed manually
away from a default value (which might be calculated by an appropriate
function, as in Pauls example). It seems quite probable that it's not often
possible or useful to assign primary keys in this way, but it can be: small
and very slowly growing table, the PKs are mnemonics (very helpful for ad-hoc
queries when used as foreign keys), and new records for this table are only
entered locally, no multi-user complications. To me an additional
autoincrement PK looks like overkill for this case.

I'm beginning to think this might not be a special Dabo problem. While my old
Delphi 6 application has no problems with manually created PKs, I suspect
ADO.NET or the QtSQL module might not like them either. Will experiment a
little more if I can find the time.

Thanks again,
Sibylle

--
Dr. Sibylle Koczian


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/200809231629.06954.Sibylle.Koczian@...

[Ed Leafe]

On Sep 23, 2008, at 9:29 AM, Sibylle Koczian wrote:

> newrec =  False
> diff =  {'idn': (u'', u'AC2'), 'amount': (None, Decimal("345.6"))}

        Wow, thanks for all the information! That makes it a lot easier to  
figure out what's going on.

        I've quoted the above because it showed me what the problem is. Note  
that even though this is a new record, 'newrec' is False. Digging into  
the code, the problem is because of the system we use to track new  
records: we store the PKs of new records as dictionary keys to later  
on identify them. In your case, the default value of the PK in the new  
record (i.e., "") was stored as the key. Later on, when you tried to  
save, the PK value was 'AC2'; since this value was not in the keys of  
new records, the code assumed it was not new, and thus did not try to  
save the PK. This also explains the one traceback you got: that was  
the result of trying to move to the record whose PK was the empty  
string, since that's what the new records dictionary had saved.

        I need to spend a bit of time to figure out the best way to correct  
this problem, but right now I'm at work and won't be able to focus on  
this until later tonight at the earliest.

        Also, it is expected behavior that your local copy of the data would  
not have data that was modified by a trigger on the server; likewise,  
if another user had modified a record that you have in your local  
dataset, you wouldn't see their changes, either, as these only exist  
on the server. In order to get that data, you would need to call  
self.requery() from the bizobj's afterSave() method.

-- Ed Leafe





_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/EA847A75-3E42-4041-873B-06F4D30065E4@...

[Sibylle Koczian-2]

Am Dienstag, 23. September 2008 16:43:38 schrieb Ed Leafe:

> On Sep 23, 2008, at 9:29 AM, Sibylle Koczian wrote:
> > newrec =  False
> > diff =  {'idn': (u'', u'AC2'), 'amount': (None, Decimal("345.6"))}
>
> Wow, thanks for all the information! That makes it a lot easier to
> figure out what's going on.
>
> I've quoted the above because it showed me what the problem is. Note
> that even though this is a new record, 'newrec' is False. Digging into
> the code, the problem is because of the system we use to track new
> records: we store the PKs of new records as dictionary keys to later
> on identify them. In your case, the default value of the PK in the new
> record (i.e., "") was stored as the key. Later on, when you tried to
> save, the PK value was 'AC2'; since this value was not in the keys of
> new records, the code assumed it was not new, and thus did not try to
> save the PK. This also explains the one traceback you got: that was
> the result of trying to move to the record whose PK was the empty
> string, since that's what the new records dictionary had saved.
>

Thank you, now I understand what happens.

> I need to spend a bit of time to figure out the best way to correct
> this problem, but right now I'm at work and won't be able to focus on
> this until later tonight at the earliest.
>

After thinking about it some more: _should_ it be corrected? Or wouldn't it be
quite acceptable if manually constructed PKs could only be assigned by some
workaround (like entering them in a textbox without data binding and
assigning them to the right database field by code)? Because it certainly is
and should be a non standard practice. But I haven't tried this out and at
the moment I don't really know how to code such a workaround.

Thinking a little more about this leads me to a wish: could the dBizobj class
allow the manual assignment not only of one UserSQL (select) statement, but
of user defined statements for INSERT, UPDATE, DELETE? That's possible, but
not mandatory with ADO.NET, for example, and I think it's a good thing.

> Also, it is expected behavior that your local copy of the data would
> not have data that was modified by a trigger on the server; likewise,
> if another user had modified a record that you have in your local
> dataset, you wouldn't see their changes, either, as these only exist
> on the server. In order to get that data, you would need to call
> self.requery() from the bizobj's afterSave() method.
>

I see.

Thank you,
Sibylle

--
Dr. Sibylle Koczian


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/200809241818.32414.Sibylle.Koczian@...

[johnf]

On Wednesday 24 September 2008 09:18:32 am Sibylle Koczian wrote:
> After thinking about it some more: _should_ it be corrected? Or wouldn't it
> be quite acceptable if manually constructed PKs could only be assigned by
> some workaround (like entering them in a textbox without data binding and
> assigning them to the right database field by code)? Because it certainly
> is and should be a non standard practice. But I haven't tried this out and
> at the moment I don't really know how to code such a workaround

Sure in the beforeSave() or at some proper place in your code
self.BizObj.setFieldVal("fieldName", value)

--
John Fabiani


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/200809241013.41352.jfabiani@...

[Paul McNett]

johnf wrote:

> On Wednesday 24 September 2008 09:18:32 am Sibylle Koczian wrote:
>> After thinking about it some more: _should_ it be corrected? Or wouldn't it
>> be quite acceptable if manually constructed PKs could only be assigned by
>> some workaround (like entering them in a textbox without data binding and
>> assigning them to the right database field by code)? Because it certainly
>> is and should be a non standard practice. But I haven't tried this out and
>> at the moment I don't really know how to code such a workaround
>
> Sure in the beforeSave() or at some proper place in your code
> self.BizObj.setFieldVal("fieldName", value)

And I'll reiterate again that I do this all the time, by using
biz.DefaultValues["pk"] = myFunc. It works without any special workaround.

Paul


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/48DA7745.90100@...

[Sibylle Koczian-2]

Am Mittwoch, 24. September 2008 19:22:13 schrieb Paul McNett:

> johnf wrote:
> > On Wednesday 24 September 2008 09:18:32 am Sibylle Koczian wrote:
> >> After thinking about it some more: _should_ it be corrected? Or wouldn't
> >> it be quite acceptable if manually constructed PKs could only be
> >> assigned by some workaround (like entering them in a textbox without
> >> data binding and assigning them to the right database field by code)?
> >> Because it certainly is and should be a non standard practice. But I
> >> haven't tried this out and at the moment I don't really know how to code
> >> such a workaround
> >
> > Sure in the beforeSave() or at some proper place in your code
> > self.BizObj.setFieldVal("fieldName", value)
>
> And I'll reiterate again that I do this all the time, by using
> biz.DefaultValues["pk"] = myFunc. It works without any special workaround.
>

Yes, if there is a function producing the PKs you want. Not quite so simple if
you invent each one (abbreviations for example). In that case the value would
come from some control in the form, and I don't really think myFunc should
have to know about the UI. I will play around with this and see where I get.

Sibylle

--
Dr. Sibylle Koczian


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/200809241943.32943.Sibylle.Koczian@...

[Paul McNett]

Sibylle Koczian wrote:

> Am Mittwoch, 24. September 2008 19:22:13 schrieb Paul McNett:
>> johnf wrote:
>>> On Wednesday 24 September 2008 09:18:32 am Sibylle Koczian wrote:
>>>> After thinking about it some more: _should_ it be corrected? Or wouldn't
>>>> it be quite acceptable if manually constructed PKs could only be
>>>> assigned by some workaround (like entering them in a textbox without
>>>> data binding and assigning them to the right database field by code)?
>>>> Because it certainly is and should be a non standard practice. But I
>>>> haven't tried this out and at the moment I don't really know how to code
>>>> such a workaround
>>> Sure in the beforeSave() or at some proper place in your code
>>> self.BizObj.setFieldVal("fieldName", value)
>> And I'll reiterate again that I do this all the time, by using
>> biz.DefaultValues["pk"] = myFunc. It works without any special workaround.
>>
>
> Yes, if there is a function producing the PKs you want. Not quite so simple if
> you invent each one (abbreviations for example). In that case the value would
> come from some control in the form, and I don't really think myFunc should
> have to know about the UI. I will play around with this and see where I get.

No, the biz shouldn't be aware of the ui at all. If it were me, I'd keep
the PK invisible from the UI (and keep it meaningless), and just define
another field for the abbreviation field that may well be unique but
isn't *the* pk.

Paul


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/48DA7DA3.2080804@...

[Uwe Grauer-5]

Paul McNett wrote:

> Sibylle Koczian wrote:
>> Yes, if there is a function producing the PKs you want. Not quite so simple if
>> you invent each one (abbreviations for example). In that case the value would
>> come from some control in the form, and I don't really think myFunc should
>> have to know about the UI. I will play around with this and see where I get.
>
> No, the biz shouldn't be aware of the ui at all. If it were me, I'd keep
> the PK invisible from the UI (and keep it meaningless), and just define
> another field for the abbreviation field that may well be unique but
> isn't *the* pk.

This is always the better way to handle it - except for cases where
you can't change the data structure of a already existing database.

Uwe


_______________________________________________
Post Messages to: Dabo-users@...
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/48DA80D0.9090708@...