************************************* * * * DB/C Newsletter * * May 2000 * * * ************************************* News and Comments The antitrust lawsuit between Microsoft and 19 states and the US government looks like it will continue for many years. It is unclear what impact, if any, the lawsuit will have in the near future, but the long term consequences could be quite dramatic for the computer industry. Imagine the US government deciding which parts of Windows should be bundled with Internet Explorer, Office, or left in the base operating system. Microsoft hasn't done a great job in its API design over the years, but I shudder to think about what it would look like with Janet Reno and company dictating Windows API design decisions! Those of us in the DB/C world shouldn't have too much concern because of the old mantra that I preach frequently - PORTABILITY. If Windows ceases to be a major operating system, there will be replacements - and DB/C will run on them. This month's newsletter contains some new Frequently Asked Questions. Printing is an area that is the source of many questions. We don't address any DB/C printing questions this month, but we'll dedicate a full article to answering questions about printing in a future newsletter. don.wills@dbcsoftware.com ****************************************************************************** DB/C Frequently Asked Questions Question: Can I use DB/C JX to compile my existing DB/C programs into Java Applets so that they can run in a browser? Answer: The technically correct answer to this question is yes. However, in most situations, several problems exist that cannot be alleviated and thus the results will be completely unsatisfactory. The first of these problems is related to bandwidth and program size. A typical DB/C DX program that compiles into a 150,000 byte .dbc file will typically be four or more times larger (before compression) when compiled with DB/C JX into a Java .class file. The DB/C JX runtime classes contained in dbcjxl.jar must also be available to run this program. The dbcjxl.jar file is about 300,000 bytes in size. Thus to execute just one program (no answer program, no menu program, etc.) you need to download at least 500,000 bytes. At typical dial-up speeds (40,000 bps), the download time is more than two minutes. The second problem has to do with the 25 by 80 screen size that is used by most DB/C programs. When running their browser, most users waste a large part of their screen on adornments - toolbars, status bars, etc. The size of the Applet rectangle necessary to fit a 25 by 80 screen is too large to fit inside the browser window without having to scroll quite frequently. The third problem has to do with Microsoft Internet Explorer's miserable support of Java. To be able to run substantial Java applications, each user will need to download the latest Java runtime web browser plug-in from Sun. Thus, JX compiled Applets are only useful in a closed environment, like a corporate intranet, where each machine can be controlled and configured. But in an environment like that it's much easier to just run either DB/C DX or DB/C JX with compiling to Java applications, not Applets. ----------------------------------------------------------------------------- Question: When using DB/C FS, why does my Microsoft Access query take so long? Answer: Microsoft Access sends database queries to the database front end that Microsoft calls the 'Jet Engine'. This software converts even the simplest query into a template-driven SQL SELECT statement that is quite complicated. Specifically, 'Jet' generally creates a WHERE clause that contains an expression with 10 or more OR operators. This statement is sent from 'Jet' to DB/C FS via ODBC. DB/C FS attempts to optimize each SELECT statement by using the appropriate index to satisfy WHERE and ORDER BY clauses, but when the statement is complex, DB/C FS falls back to reading the entire file sequentially, selecting records that match the WHERE clause, and then sorting the result to match the ORDER BY clause. Fortunately, Access provides a way to bypass the 'Jet Engine'. This feature is called the 'Pass Through Query'. With this feature you specify the SQL SELECT statement manually. In general, SELECT statements with a few joined tables and simple WHERE and ORDER BY clauses will be optimized by DB/C FS. For large text files, the performance difference between an optimized and a non-optimized SELECT can be quite large. The same record retrieval that takes a couple of seconds with 'Pass Through' can take many minutes with 'Jet'. ----------------------------------------------------------------------------- Question: With the SQL interface of DB/C DX and DB/C JX (SQLEXEC), can I make two concurrent connections to different SQL databases? Answer: No, the current implementation of SQLEXEC only allows for connecting to a single database at any given time. You can connect to one database, process some records, disconnect from that database, and then connect to another database. ----------------------------------------------------------------------------- Question: I would like to update DB/C data files concurrently with an existing DB/C application and with another application that uses SQL. DB/C FS seems to allow this, but data integrity must be maintained. How does the locking mechanism of DB/C FS work in conjunction with FILEPI and record locking in DB/C DX and DB/C JX? Answer: When a program executes an SQL SELECT FOR UPDATE, DB/C FS creates a record lock on each record as it is fetched. The intent is for that record lock to work in conjunction with DB/C record locking (but not FILEPI) so that data integrity can be maintained. However, to work correctly, DB/C FS must use the same file offsets for record locking that DB/C DX and DB/C JX are using. As long as DX and FS are running on the same operating system, you shouldn't need to do anything special - all will work. If you are using SAMBA or something like that to allow DB/C Windows applications to access files on the UNIX disk, then the offsets probably don't match and the record locking won't work. A good discussion of this is found in the February 2000 DB/C Newsletter. Thus, FILEPI is useless in this situation. Your DB/C programs need to be using record locking to work effectively in a DB/C FS environment with SQL applications where both are concurrently updating records. ****************************************************************************** DB/C Class Schedule Class: DB/C DX and JX Language Fundamentals Date: July 10-12, 2000 Location: Oak Brook, Illinois For information, contact Judi Tamkevic at: voice 630.572.0240 email admin@dbcsoftware.com ****************************************************************************** Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you when it is produced, just send an email message to 'request@dbcsoftware.com' and put the line 'subscribe dbcnews' in the body of the email message (omit the ' characters). The newsletter will be delivered to the email address from which the message was sent. To stop delivery, put the line 'unsubscribe dbcnews' in the body of the message.