*** reinhard has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<kilo> good morning
*** sjc has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV_ has quit IRC
*** johannesV has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
<johannesV_> palim palim
*** dimas has joined #gnuenterprise
<kilo> ping
<dimas> pong
<dimas> hello all
*** reinhard has quit IRC
*** johannesV has quit IRC
*** johannesV_ has quit IRC
*** johannesV has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** havoc_ has joined #gnuenterprise
*** havoc has quit IRC
*** holycow has quit IRC
<kilo> johannesV: in postgresql using native boolean datatype, if the db engine gets a NULL value for that, what does it do? does it default to False?
*** docelic has quit IRC
*** sjc has quit IRC
<johannesV> None?
<kilo> ?
<btami> johannesV: the firebird dbdriver uses a boolean domain without 'DEFAULT 0' clause for boolean values
<btami> if i use a checkbox on a form, and create a new record without touching the checkbox field
<btami> it doesn't saved
<btami> without any error message!
* johannesV phone ...
<btami> bbl
*** btami has quit IRC
<johannesV> back
<johannesV> ok, so what's the matter with that boolean thingy ?
<kilo> hmm
<kilo> ok
<kilo> there is a checkbox on the form, and we want to create a new record
<kilo> we do NOT touch the checkbox
<kilo> and None is sent to the db driver
<kilo> for the field the checkbox is linked to
<kilo> and firebird does not stores it
<kilo> as Boolean is a smallint domain there
<kilo> allowing only 1 or 0
<johannesV> well, i think if you don't touch the checkbox it won't be sent back to the database
<kilo> and it does not know what to do with None
<johannesV> since the field hasn't been changed
<johannesV> what sql-command results if you do this (check with --debug-level=3)
<johannesV> is the boolean column included in the insert statement ?
<johannesV> i don't think it will
* kilo just dismangled his database...
<johannesV> yeah, doing such a test with my postgres only contains those fields which i've changed. so the untouched checkbox is not included in the insert-statement
<johannesV> so if you have defined a 'default' value for a column which is not given in the statement or beeing null, the db will set it's value to this default
<johannesV> kilo, i think your domain should allow 0, 1 and NULL anyway ...
<kilo> where is it defined...
<kilo> creation.py
<johannesV> yeah
<johannesV> but it's defined without a null constraint ... :(
<johannesV> i mean without nulls beeing allowed
<johannesV> i'm just checking it with a testcase on my firebird here
<kilo> thx
<johannesV> ok, got it
<johannesV> we need to change Creation.py for interbase a bit ...
<johannesV> kilo, please svn update and retry ...
<kilo> thx
<kilo> but i am still tring to rebuild the db first...
<dimas> what about to put gnue installation on samba share for all windows users? would that work?
<kilo> i want this:
<kilo> http://www.daskeyboard.com/images/face-profile-bigger.jpg
<kilo> thx johannesV, it works noe
<johannesV> great :)
<dimas> anybody, how to compare variable with cfield in <condition> ?
<johannesV> cconst ?
<dimas> how to put in cconst for example what mx.DateTine.now() would return?
<dimas> Time
<johannesV> in forms ?
<dimas> yes
<johannesV> you migth want to use a parameter instead of a const ...
<dimas> any examples of that?
<johannesV> appserver's sample.gfd
<johannesV> instead of cconst you'll use cparam
*** jamest has joined #gnuenterprise
<dimas> johannesV: if I put setParameter somewhere in ON-INIT will it be done before datasource initialization?
<johannesV> hmm, not sure, you might have to try
<dimas> ok
<reinhard> strange day today
<reinhard> I actually get stuff done
<reinhard> I'm completely unused to this feeling
<johannesV> do you get the stuff done by others or by yourself :)
<reinhard> both ;-)
<jamest> :)
<jamest> are datasources stable again?
<reinhard> what do you mean with "stable"?
<reinhard> stable as in "should work": yes
<reinhard> stable as in "no planned changes any more": no
<jamest> as i jamest can put into production with a reasonable expectation that it won't purge my sales table
<jamest> :)
<reinhard> there haven't been an major changes for a few weeks
<reinhard> and AFAICT several people use svn here
<kilo> nothing is sweeter than purging a sales table...
<jamest> ok
<jamest> my warehouse people just told me they are ready (after 6 month delay) to start using my stuff
<jamest> but i'm using a more recent svn than i have in production that that stuff
*** kilo has quit IRC
<jamest> hmmm
<jamest> one side effect of the new datasources
<jamest> forms simpleQuery trigger function no longer has access to the fields in a datasource other than then PK (the oid field in postgresql's case)
<jamest> i'd imagine because nothing ever calls the referenceField function for datasources that aren't attached to blocks
<reinhard> sounds logical
<reinhard> you have a datasource w/o block and you use that for a simpleQuery?
<jamest> yes
<jamest> i use these as lookup datasources
<reinhard> maybe simpleQuery could be changed to implicitly reference fields that are given in the query
<jamest> well
<reinhard> hmmm
<jamest> in this case i'm referencing the UPC code of an item
<jamest> to pull the make, model, description
<reinhard> you don't define at all which fields to query
<jamest> which are not part of the query
<jamest> right
<reinhard> so it's another case of select *
<reinhard> right?
<jamest> i don't even think the trigger namespace has a way to reference fields
<jamest> yes
<jamest> so I'm wondering if simpleQuery should accept a list of field names that should be pulled
<jamest> or if there is a better, cleaner way to do this
<reinhard> was thinking exactly the same
<reinhard> list of field names as parameter to simple Query
<reinhard> hmmm
<reinhard> that parameter would have to be passed to createResultSet too
<reinhard> it should *not* (IMHO) do an implicit referenceField
<reinhard> becuause if you first simpleQuery foo and bar
<reinhard> and then, later, on the same datasource simpleQuery baz and frob
<reinhard> the second query will do a select foo, bar, baz, frob
<reinhard> or what would you think?
<jamest> i was just wondering about that
<jamest> with simpleQuery (my usage) that case wouldn't happen
<jamest> and even if it did it would only pull a few fields that I could ingore
<jamest> ignore
<reinhard> sure
<jamest> however
<reinhard> but it is not *correct*
<reinhard> :-)
<jamest> i don't like it
<reinhard> anyway I am wondering why you don't use master/detail
<jamest> ?
<reinhard> but I guess the case is a little more complex than I see
<jamest> i do this for lookups
<jamest> the user enters into the zipcode field 66502
<jamest> a simpleQuery looks up the city, state and puts Manhattan, KS in the city state fields
<jamest> zip, city, state all existing in the customer block
<reinhard> are they read only form entries, or are they redundant data in customer?
<jamest> in our system they are stored with the records
<reinhard> ok
<jamest> legacy thing
<jamest> i have disabled the hand editing
<jamest> but that was the simple case
<jamest> in my current case i'm looking up item info based upon the upc code
<jamest> for our warehouse app
<jamest> to validate the item they are shipping matches the model number in our inventory
<jamest> warehouse works with a barcode scanner, phone reps work from model numbers
<reinhard> anyway
<jamest> you think that could be done with master detail?
<reinhard> independently whether it makes sense in a specific case to use simpleQuery or not
* jamest thought it would be overkill to have a whole block for this :)
<reinhard> if we want to have that function, it needs the fieldlist parameter IMHO
<reinhard> I always did a block for such stuff
<reinhard> I had pretty much the same in my hotline app
<reinhard> showing phone and email on form for the selected customer etc
<reinhard> and looking up whether customer has support contract
<reinhard> the nice thing would be
<reinhard> if you made, in the simple case, zipcode a detail of customer
<reinhard> the query would run automatically
<reinhard> hmmm.. or not?
<jamest> i wonder if simple query should reference the fields, perform the query, then unreference the fields
<reinhard> I think passing the fields to createResultSet would be better
<jamest> i didn't think master/detail did lookups on focus out
<reinhard> jamest: you're right, it doesn't
<reinhard> you would have to make the zipcode entry a lookup field
<reinhard> tied to the zipcode datasource
<reinhard> wait
<reinhard> crap
<reinhard> I'm getting old
<jamest> createResultSet doesn't accept field references
<reinhard> please ignore everything I've said so far
<reinhard> <datasource explicitfields="foo,bar,baz"> should do the trick
<jamest> doh!
<reinhard> :q
<reinhard> ergh wrong window
<jamest> i saw explicitfields in the code
<jamest> and didn't think anything of it :)
<reinhard> it wasn't you?
<reinhard> then it must have been jcater who invented it
<reinhard> at least it was already there when I started
<reinhard> bbl phone
*** btami has joined #gnuenterprise
<jamest> new login dialog?
<reinhard> yes brand new :)
<reinhard> any troubles?
<reinhard> should actually be upward compatible (kinda)
<jamest> nope
<jamest> what's it do different?
<reinhard> but it has some new nice features
<reinhard> like it can ask for stuff like company in a multi-company environment
<reinhard> with dropdowns showing all available companies
<jamest> hows that work with datasources?
<reinhard> brb phone again
<jamest> all companies data  in a single backend?
<dimas> why could parameters's default setting not work when for the same form works when passed from command line?
<dimas>   <parameter name="today" default="2005-05-18"/>
<jamest> hmmm
<dimas> sorry
<dimas> works now
<jamest> my one use of parameter shows a type setting of sting
<jamest> string
<dimas> but strange, i only restart navigator
<reinhard> jamest: all companies in a single db is what appserver supports now as the first alternative
<reinhard> we plan to eventually extend it to further alternatives like
<reinhard> separate tables per company
<reinhard> separate db per company
<reinhard> however appserver would take care for that
<jcater> does the login system still generally follow the same principle?
<reinhard> and as a user you enter your company when you log in
<reinhard> yes
<jcater> in which it asks the database driver what fields are needed for logging in?
<jcater> cool
<reinhard> yes
*** yure has quit IRC
<jcater> I saw all the code in the login handler
<reinhard> however for example appserver says "I need username, password, and company"
<reinhard> (if configured to have authentication and multi company)
<reinhard> and also with company passes a list of valid selections
<reinhard> so the user gets presented a dropdown instead of an entry
<reinhard> or, even better, 2 dropdowns; one with company code and the other with company name
<reinhard> so he can select whatever he likes more
<dimas> could be also default setting from user's profile or config
<reinhard> dimas: right
<jamest> hmmm
<jamest> i used to do
<jamest> block.clear()
<jamest> block.field.set("value")
<jamest> block.field2.set("value")
<jamest> block.commit()
<jamest> to commit to blocks that didn't have a UI attached
<jamest> with latest svn block.commit() claims depreciated and doesn't work
<jamest> however form.commit() gives no error but doesn't commit anything either
<jamest> would this usage have changed?
<reinhard> this block.commit vs. form.commit is actually a quite old topic IIRC
<reinhard> AFAICT form.commit should do it
<reinhard> form.commit should commit all blocks that have changes
<reinhard> yes
<dimas> johannesV: OnActivation is fired later
<jamest> hmmm
<jamest> what's happening is that the data entry blocks are unbound
<jamest> and the bound block is not accessed by the user
<jamest> the form.commit() seems to leave the form in a state of unsaved
<jamest> so they clear the block which rolls back the insert statement that was issued against the hidden block
<reinhard> the form.commit() should actually do everything: insert statement, commmit statement, and (if not turned off) requery statement
<jamest> that is what it reads like
<dimas> johannesV: working with On-Startup
<johannesV> dimas, great !
<johannesV> bbl
*** dcmwai has joined #gnuenterprise
<reinhard> jamest: you're finding out something?
<reinhard> (just as a forewarning: I will have to leave in about 1.5 hours)
<jcater> my guess
<jcater> (I've been out of the code a while)
<jcater> I'm not sure it's still guaranteed that a block will have at least an empty resultSet
<jcater> so the logic of when an empty resultSet is created might have changed
<jcater> to be related to display?
<reinhard> a block will still always have at least one record
<jcater> is that still true?
<jcater> I knew it was at one point
<reinhard> and if the resultSet is empty, a new record will be inserted
<reinhard> yes
<jamest> i'm not seeing where it's going wrong yet
<jcater> ok, well I'll close my kate editor and stay out :)
<jamest> odd
<jamest> the commit is resulting in an immediate rollback
<jamest> w/o error
<reinhard> huh?
<reinhard> the backend gets a commit and does a rollback?
<reinhard> or you call commit and the backend gets a rollback?
<reinhard> did you look at --debug-level=3 ?
<jamest> yeah, sorry
<jamest> user
* jcater hands jamest a mallet
<jcater> that should help w/that pesky user problem
<jamest> DB003: 0:01:23.271 [Connection:259] DBSIG2 Statement: INSERT INTO item_transactions (target, type, source_key, qty, note, source, item_id, item_sheet_cost) VALUES (%(new_target)s, %(new_type)s, %(new_source_key)s, %(new_qty)s, %(new_note)s, %(new_source)s, %(new_item_id)s, %(new_item_sheet_cost)s)
<jamest> DB003: 0:01:23.271 [Connection:260] DBSIG2 Parameters: {'new_type': 'decrease', 'new_source': 'shipping', 'new_target': 'onhand', 'new_item_id': 3693, 'new_item_sheet_cost': None, 'new_qty': '1', 'new_source_key': 'jamest', 'new_note': 'APP:shipping.gfd'}
<jamest> DB003: 0:01:23.273 [Connection:493] DBSIG2 Rollback
<jamest> oh
<jamest> my
<jamest> issuing a block.clear() now issues a rollback against the connection?
<reinhard> didn't it do that since ever?
<reinhard> I can't remember changing *that*
<reinhard> however it might be that we misread something
<jcater> iirc, it's done that for as long as I remember
<jcater> not saying that's correct
<reinhard> ok, then I say it's correct :)
<reinhard> with the (new, appserver specific) situation that insert/update/delete statements can arrive at the backend before the commit is done
<reinhard> a clear *has to* do the rollback to undo these statements
<jamest> that's not the issue
<reinhard> actually that situation is not exactly appserver specific, could also happen with 2-tier if you have triggers or stored procedures
<jamest> at one time I had unbound datasources
<jamest> well, still do actually
<jamest> it contains a statesetrow
<jamest> that block isn't tagged as saved during commit
<reinhard> a statesetrow?
<jamest> static
<reinhard> so it's actually a static datasource?
<jamest> er, yes, sorry
*** SachaS has joined #gnuenterprise
<jamest> the main block the users interact with isn't bound to anything
<jamest> i did used to use an unbound ds
<jamest> but i had to add the staticsetrow at some point because <insert reason I don't recall that broke unbound datasources>
<reinhard> actually it should be unbound
<reinhard> my understanding always was that static should be only be used read-only
<jamest> that was how it originally was
<jamest> i don't remember what changed
<jamest> i'll flip it back and see what breaks :)
*** titopbs has joined #gnuenterprise
<reinhard> hmmm
<reinhard> at first sight the static datasource should have no bound fields at all
<reinhard> so it should never enter a "dirty" state
<reinhard> except when it serves as a master...
*** dcmwai has quit IRC
*** wendall911 has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** johannesV has quit IRC
*** wendall911 has quit IRC
*** johannesV has joined #gnuenterprise
*** btami has quit IRC
<reinhard> off to lug meeting
<reinhard> cu
*** reinhard has quit IRC
*** mnemoc has quit IRC
*** mnemoc has joined #gnuenterprise
*** SachaS has quit IRC
*** SachaS has joined #gnuenterprise
*** sjc has quit IRC
*** Amorphous has quit IRC
*** sjc has joined #gnuenterprise
*** Amorphous has joined #gnuenterprise
*** Morphous has joined #gnuenterprise
*** mnemoc has quit IRC
*** mnemoc has joined #gnuenterprise
*** johannesV has quit IRC
*** SachaS has quit IRC
*** sjc has quit IRC
*** titopbs has quit IRC
*** sjc has joined #gnuenterprise
*** sjc has quit IRC
*** kilo has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** titopbs has joined #gnuenterprise
*** kilo has quit IRC
*** titopbs has quit IRC
*** wendall911 has joined #gnuenterprise
*** mdean has joined #gnuenterprise
*** wendall911 has quit IRC