************************************* * * * DB/C Newsletter * * February 1999 * * * ************************************* News and Comments I must sound like a broken record. DB/C JX 2.0 is still in beta testing and we have not yet started full beta testing of DB/C DX 10.0, although DX is in limited beta testing at one customer location. That customer is testing a sophisticated DB/C GUI application that requires access to DB/C files on a UNIX server. Their initial plan of using NFS to access the files on the UNIX system didn't perform well enough to deploy. Hopefully, the combination of DB/C DX and DB/C FS will perform acceptably. We'll be providing some DX/FS performance comparisons in a future newsletter. This month has been an interesting month for Microsoft. As I see it, two important changes have occurred. First, many computer industry pundits are now seriously talking about the breakup of Microsoft. This is primarily due to Microsoft's botched defense in the antitrust trial, but is also because of the testimony by many companies in the computer industry. Even Compaq was fearful of Microsoft. I'm not sure a breakup will happen, but at the very least, Microsoft's reputation has been severely tarnished by the trial. More importantly, Microsoft seems to be backing away from support of Java. There are rumors of Microsoft creating a Java-like language named Cool that doesn't use any Javasoft technology. If Microsoft ceases supporting and enhancing Visual J++, those developers who have embraced Microsoft enhancements to Java and are using the non-portable Microsoft Java classes (J/Direct, etc.) will really be in trouble. This situation is exactly what I've been preaching about for many years with regard to DB/C. I'll reiterate: *** Portability is the most important aspect of application software. *** Without portability you are forever at the mercy of some hardware or software vendor. With portability you are free to move to the next platform without having to rewrite your code. Hardware is expendable. Software is forever. Portability is what both DB/C and Java are all about. That's why we're so positive about both. This month's article is about the euro. Even though this topic might seem unimportant to non-European readers, I believe that many application systems will need to deal with this issue sometime in the next few years. We've also included more Frequently Asked Questions. We'll try to include some new FAQs in each newsletter. If you have any useful questions or insights to contribute, please forward them to us. don.wills@swc.com ***************************************************************************** The Euro Most western European countries (with the notable exception of Great Britain) are in transition to a single currency, aptly named the euro. The impact on both institutions and individuals in these countries will be great. The first banking use of the euro started in January of this year. The paper euro currency will begin circulation in a couple of years. The impact on software will also be great. There are many conversion issues that are essentially being handled by reprogramming. The most visible computer issue is the euro symbol itself. To see what it looks like, go to this European Union web page: http://europa.eu.in/euro Computer hardware and software needs to be changed so that the euro symbol will appear on keyboards, displays and printers. Various companies and other organizations have been busy working on this issue. Unfortunately, there is no general consensus on what the encoding for the euro symbol will be. The ISO 8859 standard has been updated to ISO 8859-15 which specifies the euro symbol byte code value is 0xC4. Most UNIX vendors, printer vendors and many dumb terminal makers will use this value for the euro symbol. In Unicode (used by Java), the value of the euro symbol is '\u20AC'. For Windows, Microsoft assigned the euro symbol the byte code value 0x80. As usual, it is programmers who will have to deal with these differences. There may be some impact on existing DB/C applications. Most non-English speaking European countries have already had to deal with characters outside the basic printable ASCII characters (0x20 - 0x7E). In DB/C 9.1, to store characters above 0x7F in a file, the DBC_ICHARS=ON runtime option must be specified. This runtime options allows characters between 0x80 and 0xF9 (inclusive) to be stored in text files. With this option specified, file compression is disabled. The biggest impact on DB/C users is for runtime environments that contain multiple operating systems. Using DB/C FS, it is easy to link Windows and UNIX systems in a single operating environment. In these mixed environments, if the euro symbol is stored in files as 0x80, UNIX applications will need to translate the records as they are read and written. If the euro symbol is stored as 0xC4 then Windows application will need to do the translation. DB/C DX and DB/C JX will provide these capabilities. Here are two additional URLs that provide information about the euro: http://www.microsoft.com/windows/euro.asp http://www.hp.com/euro ***************************************************************************** DB/C Frequently Asked Questions Question: I'm getting ready to distribute DB/C FS 2.0.4 to 20 locations. I have read the update file for changes and can see how they will impact the server. However, I noticed that the date is changed on SETUPODB.EXE. I need to know two things: 1. What changes were made to the ODBC driver in the client (FS2ODBC.DLL)? 2. Do we need to uninstall/reinstall the ODBC driver for existing 2.0.2 and 2.0.3 clients? Answer: There was a change between 2.0.2 and 2.0.3 to fix a problem involving cursors. If your application uses cursors (Access does not), then you need to reinstall when upgrading from 2.0.2. There was no change from 2.0.3 to 2.0.4 other than to update the release number (which you can see in the Control Panel), so you don't need to reinstall the ODBC driver in this situation. ----------------------------------------------------------------------------- Question: I'm writing a DB/C GUI application. I've encountered a problem trying to test for 'control has changed' on PANELs and DIALOGs. I've used various methods including QUERY after focus change, but I'm still having problems. What should I do? Answer: Use ITEM messages. To receive ITEM messages, execute this statement CHANGE resource, "ITEMON" before you show the dialog or panel resource. For text controls, you will receive an ITEM message with the new value of the control after each keystroke is pressed. This message will contain the complete, current text in the control. For other controls, you will receive an ITEM message whenever the control changes, whether by keystroke or mouse click. ----------------------------------------------------------------------------- Questions: Why can't I start the NT version of DB/C FS from the command line when it's installed as an NT service and the service is stopped? Answer: This is a limitation of DB/C FS 2.0.x. We will look into making this possible in a future release of DB/C FS. For now, if you need to run it from the command line (such as for for debugging), uninstall DB/C FS as a service first (run 'dbcfs -u') and then start it manually. ***************************************************************************** DB/C Class Schedule Class: DB/C DX and JX Language Fundamentals Date: June 1999 Location: Oak Brook, Illinois For information, contact Judi Tamkevic at: voice 630.572.0240 email dbc@swc.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@swc.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.