RE: A string parser for QBE fields (Java clone)?

You need to give D4gl a chance. It requires very little changes to existing 4gl code. It can be done simply as one function call. -----Original Message----- From: peterwiley@hotmail.com [mailto:peterwiley@hotmail.com] Sent: Wednesday, February 10, 1999 1:59 AM To: informix-list@iiug.org Subject: A string parser for QBE fields (Java clone)? Hi. Not strictly speaking an Informix question, but... Those of us who've been programming in Informix 4GL for the last 10 years++ have come to appreciate the sheer utility of the CONSTRUCT statement. Unfortunately, the attempts by Informix to provide a GUI equivalent to 4GL have failed dismally. Jury's out on D4GL, but I for one am putting no time or effort into learning it. Another proprietary 4GL? I don't think so. I'm far enough along on the Java push to think that it's going to do what I want, even without the database-aware components from 3rd party vendors such as Inprise, Symantec et al. For now, I've decided to bypass these as my previous experience has not been good; their rules of operation were frequently different from how I wanted my database activity to work. All I really need right now are Type 4 JDBC 2 drivers with at least scrollable ResultSet functionality. We've built a database currently over 30Gb using nothing but Java for data acquisition & maintenence. I've proven to my own satisfaction that I can with minimal tweaking switch database engines between Informix, Oracle & PostgreSQL. (The tweaking, BTW, is nearly all in the areas of timestamps). On to the reporting end and I want my Query by Example functionality. I've had a quick hack at it - 2 nights - and have come up with something that works, by extending JTextField. It works well enough that a second attempt incorporating the lessons from the first should give me pretty much what CONSTRUCT does, though I haven't figured out how to cluster the fields as elegantly yet. Now.... I don't really want to re-invent the wheel yet AGAIN and write another goddam string parser. I've already written enough JavaBeans to provide missing functionality in JTextField. Does anyone know where I can get the source code to one that does QBE already? Language is irrelevant; I can read/program in all the common ones & figure out most of the rest. Of course, a JavaBean with all the functionality already included would be a lot better, so I'm open to all offers. I'd prefer any replies to be to the n/g rather than to my email address, but I've listed one below that I check daily. The hotmail one, I check much less frequently. Thanks, Peter Wiley Email: peter_wil@antdiv.gov.au

On Wed, 10 Feb 1999 12:09:17 -0600, "Gabbard, Mike W." <MikeG@red-man.com> wrote: > >You need to give D4gl a chance. It requires very little changes to existing >4gl code. It can be done simply as one function call. Yes, but it suffers from a number of drawbacks, from my perspective. It's a proprietary language with limited depth of support and a limited pool of programmers. It's expensive WRT Java. Most of our development effort is in Java, and will likely stay that way. There are a lot of reasons for this, but basically no other language has the capabilities we need. I am *not* about to start embedding C or C++ calls into D4GL to handle telnet listeners, email support, sockets etc etc. Might be easy, but we've decided we're not going down that path when there's a language that already has the tools built in. Java is going into the server side engines for at least a couple of the database engines we use. I strongly doubt D4GL will. I can switch back-end database servers by changing the loaded driver & URL in Java. No code changes at all. I can connect to an Oracle database & read/write data to an Informix one, or Postgres, or any other database I can get a JDBC driver for. (Aside: Informix SE 7.2 is *much* faster on inserts than Oracle 8.0.4, using the same data source, table structure & code). I'm not running down D4GL, but the database querying side is nowhere near as important as some of the other things we're doing. I can easily point an ODBC tool to do QBE & reporting and still avoid the cost of D4GL. Sorry, but I think D4GL is a niche product good for converting R4GL apps relatively quickly & painlessly to GUI. There's no way I'd do any new development work in it, given the alternatives. I've had 12 years good service out of R4GL, but it's time to move on. What I'm looking for is a pure Java solution. Peter Wiley