Am Donnerstag, 25. September 2008 16:38:00 schrieb Ed Leafe: > On Sep 25, 2008, at 9:28 AM, johnf wrote: > > This may sound crazy but how about turning it around. Allow Dabo to > > create > > the PK (using the internal auto increment stuff). Then in your form > > over > > ride the save() and in there change the PK at the very last moment. > > > > def save(self): > > change the pk > > self.super() > > > > I think that's how I handled the problem in the past. However, > > maybe the > > framework code has changed so much that it will no longer allow the > > late > > setting. > > John, it's clearly a bug in the framework. I'd much rather fix it > than encourage crazy workarounds. (Wow, this sounds like a recent > ProFox thread!) >
I'm still not really certain if it's in fact a bug. Aren't most tables that can use a natural primary key without danger rather static or slowly growing, so it would be quite appropriate to have a separate procedure for adding new records to them, and possibly one person who does it? So if that procedure were more involved than the rest it wouldn't greatly matter? Hrabans examples seem to fall into this category, so does my own. If I were a little more experienced with Dabo I would have sent my records to the table using entry fields without data binding, a temporary cursor and my own INSERT statement. More validation before, data type conversion by hand and a requery() afterwards. But nothing really bad - I think. Tried it shortly and it worked. Greetings Sibylle -- Dr. Sibylle Koczian _______________________________________________ Post Messages to: [email protected] 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/[EMAIL PROTECTED]
