Derek Neighbors (revDeke) asked whether there were going to be Debian packages (debs) for 0.4.3 of gnue as 0.5.0 will probably be in the cooker a bit before its announced as stable and we are getting ready to dig into gnue-sb pretty hard and it will target 0.4.3 until 0.5.0 is stable.

Derek was interested whether case insensitive queries in 0.4.3 would be implemented. James Thompson (jamest) answered negatively. Derek asked will this be in 0.5.x? Or would it be too rough to back port into 0.4.3? James was pretty sure it's a trivial addition - ilike support needs added to the GCondition/Datasource. Derek thought it probably should be a property in the entry or datasource (or both). Easier to implement should be by form with a gnue.conf option (so it sets it for all forms). This would be almost enough for now, and would work well with gnue-sb. Jeff Bailey (jbailey) said my needs are mostly case insensitive matches to company names and people's names. It should be in the whole framework. Jason Cater (jcater) noticed that ilike (case insensitive like) is not sql92 (it might be sql99). Also, we can't just throw in upper() into the queries. James said he had no issue with forms doing it as my own users use mixed case data. Jeff offered pushing down to the DB layer a flag so that each DB could do this it's own way. James had to think about this more. Mike Vincent (Vee2d2) found the only solution for oracle - the use of lower() or upper() in the query.

Later, Derek asked what was the eta's on 0.5.0. Jason said it would not be within 3 weeks.

Derek Neighbors (derek) asked Mike Vincent (Vee2d2): you have 5 look up tables, i was going to make 6. My question is - do you really have your sku as C.14.4.20.1 or is it represented as C144201? Mike told it's really delimited. That way I didnt literally lock myself into 2 digits per segment as I designed it to be. Derek offered starting with what was needed and adjusting form later. Im thinking that the delimiter will be really evil for invoicing and such, i.e. i dont see delimiters for much of anything on invoices and such i encounter. Maybe i just see them as - instead of . Mike explained since he has opted to make my cross references mfg.model <-> ref, there's a much more likely need for that segment to be 3 digits. Derek noticed now it seems like this will need to be a choice 'delimiter' or no delimiter. Im planning on making the categories be 6 character varchar, so if you want to use 1 digit or 6 you can. Im giong to make the fields big enough, but will plan on delimiting (not doing optoin not to) and NOT padding - non-delimited and padded stock-keeping units can be 'second pass' type items :).

Derek asked are you trying to build in some filter mechanism here? Very generically im thinking - six category tables with a segment and a desc (As well as id). Then you have your item and it has id cat1 cat2 cat3 cat4 cat5 cat6 which holds the segments (/me suspects will 'build' the number form the segments as well and store it in a field) even though it could be calculated (for flexibility) later on. I imagine some folks will want free form ability its the cross reference table here that is throughing me for a loop. I think i get what your driving at just not sure how to make it generic. Mike agreed - I can see this as being specific to my needs. But I need to have a way to correlate my #'s to my vendor's #'s. Each vendor has their own system but the one thing that remains true is the mfg's #. So I rely on that. Derek asked if he can clarify what you are trying to do - basically take manufacturer and manufacturer number and condense it to a smaller number, to include as a part of your sku. Mike confirmed that. Ok, here is what im thinking - family, manufacturer, mfg model are probably going to be universal. That is people will probably want to 'group' product types and everyone's product is manufactured by someone (even if its yourself). This way we can create a xref table as if all tables are generic we dont want to make 6 xref tables. Actually i guess family could still be generic. So what if i make manufacturer table and mfg model number (which is really an Xref table), then 4 generic 'category' tables - will this work for you? Of course manufacturer table should be more than - id, segment, desc - but i want to get something usable quick.

He did not fancy doing full contact tables for manufacturer at this point and asked are your manufacturers and vendors one in the same? Mike said not at all.. - he could source the same manufacturer's goods from multiple vendors. Derek said that, in that case, there was probably no need to record contact details for the manufacturers, at least at first. /me has to keep telling self - something is better than nothing, dont over engineer thats what gnue 'proper' will be for ;)

Matthew Palmer (wombat2) said what he didn't see on the website is any "testimonials". I'm looking at getting GNUe accepted as the replacement for Access here at work. Is anyone willing to stand up and say "at this moment in time I'm doing X with GNUe"? I can speil about "it's good, it's free, it's what we should use" until I'm blue in the face, but my bosses like to say "Hmm, we're not going it alone". Derek Neighbors (derek) listed some GNUe users: we have large university that uses it (one you would recognize) and very large local government using it. Neither will go on record to talk about it, but likely would talk to an individual about it. We have a magazine reseller (one of the largest if not the largest) that will use and speak publically about it, a small bookstore using as backend to a l'ane Point of Sale and two or three more companies getting ready to transition to it. Matthew was interested what sort of uses are they putting it to? Ephemeral stuff, or core business functions? And are they using the prewritten stuff, or doing a lot of development of their own stuff? Derek explained that GNUe has 2 companies that supoprt and consult on it out side the United States, one in Lithuania and one in Argentina. Matthew asked whether all these users use Designer with Forms and Reports to write all of their stuff and Derek confirmed that. Derek also noticed, that those that are adopting as we speak they will be using GNUe Small Business, gnue-sb, mostly for backend manufacturing. It is being written as we speak so they are 'early adopters'. Matthew explained his situation - my boss, many years ago, started writing an Access app to do some of the mgmt of this company. It's now blown out, and I was hired (mostly) to convert it to something more reliable. Since a 300MB chunk of Access data doesn't scale real well. Derek offered using a tool, called pgadminII - it will quickly convert your access to postgres. You can then use gnue wizards to make forms from those tables VERY quickly. The only real work you will have to do that isnt 'busy' work is the 'code' to do 'special' things. All data handling will be handled for you.

Derek Neighbors (grassHopper) said that GNUe Small Business was not ready for prime time usage - 0.1 should be out shortly but it will be product management and contact management in a base form - you can grab the cvs. There was a createdb.sql script for PostgreSQL which needed to be run, then setup your connections.conf file to point to dbname with gnue_sb as the connection name, and start running the forms - all forms under 'item' directory should work at this point except item_maint.gfd. It was asked whether each form had to be run seperately. Christian Selig (lupo) asked if there were any navigator files in current gnue-sb?? Derek said not functioning ones - you have to run gnue-forms filename.gfd as of time of writing.

Nicholas Lee (esands) suggested that GNUe Small Business should Target sql-ledgers feature set. Except for a few niggles it does the job. Ignore SL's schema and code. Derek Neighbors (derek) disagreed - i would be much more likely to start with NOLA - /me assumes people liking sql-ledger will like it and GNUe isnt for them - those wishing to have something they can extend and has clean data structures will look for gnue-sb. He felt sql-ledger was very nice for the market that is using it - it certainly is more functional than gnue-sb as of time of writing and there is something to be said for working code :) However, he felt the inability to reconcile a ledger indicated a different target audience.