by A. A.Katz
April 2, 2001
I know I didn't blow it. I know it because I use it. I know it because Ed Hoskins called me the other night to rave about "how fast and easy it was to get the Subscriber database in shape" with dQuery/Web. Of course, we're biased, I'm the Architect and Ed is the Senior Engineer on dQuery/Web.
I noticed in the beta that it took a long time to get any feedback on dQuery. Not only did I wonder why, I actually became concerned that I might be going in a weird direction that made no sense to anyone in the world but me.
My fears were allayed, somewhat, by the slowly growing wave of surprised admiration that floated out of the beta test group as time passed. What the heck was it with this thing that kept people from jumping up and down with glee?
Well, first, it might just be the lack of documentation. This is one very, very powerful interface. Not only can you "play" with live data, you can model it, report it, convert it between databases, create it, import it, export it, filter it (at least five different ways), generate cool DEO Windows apps, Web apps and no-Click reports, modify reports, create custom views, count it, average it, mean it, sum it, copy it, navigate and save the whole darned thing as an inheritable, reusable dataModule. That's a lot to grasp in a day. Without a book!
Furthermore, I designed it to the basic dBASE historic standard: there's got to be at least three places where you can do anything. You can create queries from a whole bunch of places in a whole bunch of different ways:
Drag and Drop a table from the Navigator
Drag and Drop a table from Windows Explorer
File/New/Query From Table
File/New/Query From SQL File
Table/Create Table
Table/Copy Table To
Table/Copy Table From
Toolbutton/Query From Table
Toolbutton/Query From SQL File
Navigator/Tables/Untitled
Navigator/SQL/Untitled
Navigator/Right Click/Design Table
Command Window "Create"
Right-Click/Query From Table
Right-Click/Query From SQL File
That's fifteen options and I'm absolutely sure there's at least one or two I missed. And if you didn't know to look for them, you wouldn't know they were there. So I guess documentation is one big issue to be dealt with (which we are, check out Book Chapters from the Gold Site Main Menu page).
Another issue is the fact that the version of dQuery/Web that shipped with the first release of dB2K was a ".0" release and still had a few rough edges. Of course, dQuery/Web is also the first Open Source tool in dBASE history, so it would have been perfectly fine for the dBASE development community to smooth some of the edges themselves - and a few developers have. But far too few. I guess we've got to get the Open Source stuff going in a much more aggressive manner. And we will. What a coup! Killer code like dQuery/Web written in our own dBL language. If we ever needed proof-of-concept, there it is. Some of the best dBL sample code ever put together!
More recently, I've begun to believe that there's another issue at play here. Macho. I remember the Dark Ages when I was a Clipper programmer. Real programmers don't use a mouse! Real programmers don't use the Control Center! Real programmers don't use application generators!
Ah, the arrogance of youth. My attitude today has undergone a radical metamorphosis. In fact, my ultimate dream is that I'm sitting in front of my rear-projection high-definition TV with a can of diet coke at my side, my feet up on the coffee table, watching some mindless but wonderful diversion when a fleeting thought of a clever program pops, casually, into my mind and the darned thing writes itself!!
The job is defined and judged by what we deliver, whether that be applications or data or just the results of some complex database calculation. Not by what we write or how much we write or how elegantly we write it. I was at Comdex many years ago when a neighboring exhibitor proudly announced that their program was more than a million lines of code. Boy did my response depress them: "too bad, when you get it down to about 200,000 lines, it'll run really good!"
That's what I think about when I hear dB2K developers ask "how do I turn off dQuery/Web so it doesn't come up when dB2K comes up?". Because they want to "hand code" and don't want to be impeded by this "training wheels" interface.
Get with the program! Training wheels are terrific if they get you there twice as fast as walking does! Unless you've played with it, you have no idea how rich the options are in dQuery/Web. I remember a message that Todd Kreuter posted in the Beta-Test newsgroup, and I quote it (with apologies to Todd, who had no idea I was going to make his comments public):
"My first thoughts on dQuery/Web were it was an end user product, and I would not be using it much. I pretty much have abandoned the dataModule designer as I've found it easier to do that stuff in the source editor. Yesterday I wrote a small utility to extract information from thousands of client data paths on our networks. Information like when the directory was created, how many files it contained, date of the latest file, etc. I'm using that information to determine which data directories need to be purged. After I had the tables created, I decided to play around dQuery/Web to do the filtering, sorting, and reporting. A couple minutes later, I'm printing a report with all the _irrelevent_ information filtered out. Now that was simple!
Congratulations dBASE on dQuery/Web!"
Congratulations to Tod!. He got it, and got it early on! Just last week, Paul Franks, our international partner in the UK was telling me that he was getting a lot of calls asking "how to turn off dQuery/Web" and suggesting that perhaps it should not open by default. My theory, I told him, was that applications start with DATA and the DATA interface in dB2K is dQuery/Web.
(By the way, if you do want to turn it off so it doesn't come up when dB2K comes up, just go to Properties/Desktop Properties, click on the Applications tab and uncheck "Open dQuery at Startup" If you want to bring it up again, just create a new dataModule or edit one in the Command Window, the File/New menu or the Navigator. Any attempt to open or create a dataModule opens dQuery/Web)
I don't know if Paul's suggestion was right or my response was. All I know is that, as an end-user myself, I hate opening a brand new product and being greeted with a completely empty Window.
So what's the bottom line here? That even the most expert developers in the world get better and faster when they use tools that do the work for them - like dQuery/Web. And let's face it, we all gotta work with data. Otherwise, why are we using dB2K? dQuery/Web is a great data tool. One of the best (all due modesty notwithstanding).
I have to admit that I miss the hordes jumping up and down with glee. But there's a really cool, but strange, thing happening that almost compensates. Almost every day, as I scan the newsgroups and read my eMail, a few heads suddenly pop up out of the crowed and proclaim "Way Cool! dQuery Rocks!". Hopefully, as our documentation comes out, our product gets even easier and more powerful, and more and more dB2K users get experience playing with dQuery/Web, even the Macho developers will come to love it too!
AAK April 2, 2001