FRONTBASE NEWSLETTERS
FRONTBASE NEWSLETTERS

November 2001


Technical Support Newsletter #6

Welcome to the November issue of the FrontBase newsletter. If you have any additional feedback on this newsletter, or wish to contribute then please mail us at support@frontbase.com.


Contents

Review of the Month
FrontBase Out and About
Drivers, Plugins and DAMs
Hot Topic
Customer Support
Tell us what you're doing
Technical Tip
SQL tip
Technical Bulletin


Review of the Month

REALBasic plugin for FrontBase 3.3 or later

A new FrontBase Plugin (1.5) for REALbasic has been uploaded to our website 'Download' area. One of the main enhancements with the release is that row locking now works with DataControl. The plugin requires FrontBase 3.3, use with previous versions of FrontBase is not supported, not tested, and will likely result in problems. Note that once you install 3.3, you will no longer be able to access nor run 2.x databases, so backup BEFORE you upgrade.

The package includes a plugin for REALbasic 3.X PPC running on MacOS Classic (8/9), a plugin for REALbasic 3.X Carbon running on MacOS X, and a plugin for REALbasic applications built for Win32. All three plugins are contained in the "FrontBase Plugin" file. The "FrontBase Plugin.pdf" document contains instructions for installing and using the FrontBase Plugin for Mac OS Classic, Mac OS X, and Win32. The sample projects show how to correctly connect to FrontBase, check the session and statement objects for errors, and issue a few statements. If you need to use against a previous version of FrontBase (in particular 2.x), you can use version 1.4 of the plugin which is still available from the same place.

If you are interested in receiving beta builds, please contact brad@frontbase.com for more details.


FrontBase out and about

MacWorld 2002

Meet us in the Moscone Center, booth #2333 during Jan 8-11, 2002, Macworld in San Francisco.

FrontBase relational database showcases the UNIX power of Mac OS X and the beauty of its Aqua interface. Scalable from PowerBook to terabyte cluster, FrontBase offers the ultimate in performance and data integrity. Exclusive patented technology for zero-downtime e-commerce, and cross platform for Linux, Solaris, FreeBSD, and Windows NT/2000.


Drivers, Plugins and Dams

If you are interested in testing our beta software then please mail us at support@frontbase.com and we will gladly sign you up.

WO5 Plugin

Development work has continued as usual on our WebObjects plugin with a number of fixes going into the maintenance releases 1.5 and 1.5a this month. A summary of the most important follow:

We have also had reports of a bug in FrontBasePlugIn.updateLOBs (values in the qualifier were not up to date when inserting or updating). This problem has been addressed in the upcoming release of 1.6. This will be posted to the 'Download' section when complete.

Due to popular demand we will be including a release note with each new release of the WO5 plugin starting with 1.6.

WO5 Tech Tips:

For those upgrading their models from WebObjects 4.5 to WebObjects 5 there is a useful resource which outlines differences between the two environments. It can be found at homepage.mac.com/delta5 In addition to this article there are many other interesting others for the WebObjects developer at www.stepwise.com/Articles/

WO5 FAQ:

We have many reports of a problem where it is possible to connect WO5 to a FrontBase database but the following error is received when an attempt to run the application is made:

com.webobjects.jdbcadaptor.JDBCAdaptorException: SQLException raised when connecting : java.sql.SQLException: No suitable driver

It could be that the application is not 'aware' of the plugin. The actual problem might be that you have not added all necessary frameworks to your project. Look under External Frameworks. You need to have the JavaJDBCAdaptor.framework and the FrontBasePlugIn.framework added to your project. The latter is installed at /Library/Frameworks/. You have to actually add the FrontBasePlugIn Framework to your AppServer target. Just adding to your target (name=projectname) is not enough.

If it is a pre-built application the FrontBase plugin is not linked directly into the application. Therefore the plugin and JDBC driver must be in the CLASSPATH environment variable. Try to execute this line before running the application.

(MacOSX v. 10.1)

setenv CLASSPATH /Library/Java/Extensions/frontbasejdbc.jar:/Library/Frameworks/FrontBasePlugIn.framework
                 /Resources/Java/FrontBasePlugIn.jar

(MacOSX v. 10.0.x)

setenv CLASSPATH /Library/Java/Home/lib/ext/frontbasejdbc.jar:/Library/Frameworks/FrontBasePlugIn.framework
                 /Resources/Java/FrontBasePlugIn.jar

The reason for this is that the plugin is not built into the JavaJDBCAdaptor.framework so it is necessary to specify the location of it.

This is detailed in an FAQ (http://www.frontbase.com/faq) that deals with Web Objects 5 and FrontBase. It is often updated but if you run into issues which might prove invaluable to other developers then we can add in your suggestions, they are always appreciated.

JDBC Driver

Version 1.20.1 of the JDBC driver was posted this month.

An upcoming release of the JDBC plugin which incorporates many fixes will be uploaded to our 'Download' section soon. This package will also include release notes which detail all fixes and enhancements.

Omnis Studio

We are aware of an issue with the Studio DAM which can cause problems in mapping correct decimal places. For instance, a NUMERIC(19,2) defined on the server can appear with nineteen decimal places in Studio. This is currently being investigated and will be rectified asap.

REALBasic

As detailed above, a new version (1.5) of the RB plugin with significant enhancements is now available for FrontBase 3.3.


Hot Topic

Transaction Logging in FrontBase 3.3

Transaction logging has been significantly improved for FrontBase 3.x. By default, FrontBase 3.x maintains a transaction history log. This is a complete list, in the form of SQL statements, of all transactions that have altered data or structure in the database. Such a log therefore provides a complete history of the database development and it is possible to re-create a database from a particular starting point by essentially replaying the SQL statements of the transaction log. Such a particular starting point is either the creation of the database or the point where a backup of the database was created.

The concept of transaction logging in FrontBase serves several purposes:

  1. It provides an extra level of security against loss of data.
  2. It enables the database server to decouple its client interface handling from its handling of disk operations (i.e. the client handling does not have to wait for disk write operations to be completed).
  3. It serves as the basis for database clustering and replication.

For more details about transaction logging in FrontBase 3.3 please see a recently posted tech note available from our 'Technical Notes' section of www.frontbase.com/support


Customer Support

This month we have posted two new tech notes and an FAQ. Transaction logging and the new flat-file export / import functionality are explored in the tech notes while the FAQ deals with general import / export issues.

We also requested that developers help us by providing their exported sql files for internal testing in preparation for the upcoming release of FrontBase 3.4. Thanks to all of those that have helped us by providing these.


Tell us what youre doing

As a follow up to last month's feature on Softmagic, Inc. please see the link below for a story at MacCentral detailing the release of Project-M Lite for MacOS X. Softmagic jointly held a seminar in Seoul with Apple at the beginning of the month which had a great attendance. Softmagic showcased their product line with demonstrations along with Apple unveiling the latest release of MacOS X (10.1).

http://maccentral.macworld.com/news/0111/08.softmagic.php

This is a section that we would really appreciate your help with. We would like to know what you are doing with FrontBase, and don't spare the details!. What Front end you are using, what operating system, why you chose FrontBase, how you implemented your development and what you think of the performance? Each month we will feature the best case we get sent. Please mail your contributions to support@frontbase.com.


Technical Tip

VARCHARS in FrontBase

How much space do VARCHARs actually occupy? If you declare a 128 character long varchar, does it always occupy that much space, even if the string is shorter? If not, what's the minimum length a VARCHAR can occupy? What, for that matter, is the maximum length a VARCHAR can occupy?

In FrontBase VARCHARS are implemented as the traditional variable length character string. The implementation of variable length strings is very efficient, and there is no extra overhead associated with very long strings. Strings up to 16 bytes in length are stored directly in the row record (as if it was a fixed length string). A so-called spelling table is associated with each table and all identical variable length strings inserted in the rows of a table are only stored once. For the actual data, the space needed for the UTF-8 representation of the string is 1 or 2 bytes for each char in the string. NOTE: Since FrontBase encodes varchars very efficiently, use of variable length strings is, in general, recommended over fixed length strings.

Anything 64 characters or under is stored with the row, so there is a difference in usage between VARCHAR(1) to VARCHAR(64). VARCHAR 65+ are stored separately from the row, so it doesn't really matter how big they are.

For instance, if a column is defined as a CHARACTER with a length of less than 65 bytes, values are stored directly in the rows. If the length is over 64 bytes, values are stored indirectly.

If a column is defined as a VARCHAR with a length less than 17 bytes, values are stored directly in the rows. If the length is over 16 bytes, values are stored indirectly.

The absolute limit of a VARCHAR column in FrontBase is 2^31-1 or 0x7fffffff. This works out to about 2147483646 characters.


SQL tip

Altering the datatype of a column

FrontBase offers the possibility to change the datatype of a column. The new datatype can be a simple length adjustment or it can be a completely different datatype. When changing the datatype to a type that cannot be casted straightforwardly, a best fit will occur possibly by replacing the original value with a NULL.

Syntax: ALTER COLUMN <table name>.<column name> TO <data type>

Example: ALTER COLUMN "t1"."c1" TO Boolean;

The COLLATE option is an easy way to change the collation of a column, i.e. from no collation to, as in this example, a case insensitive collation.

Syntax: ALTER COLUMN <table name>.<column name> TO [<datatype>] [COLLATE <collation>];

Example: ALTER TABLE "t1"."c1" TO COLLATE CASE_INSENSITIVE;


Technical Bulletin

We are currently enhancing and updating our on-line documentation. If you have any particular ideas or suggestions for this process then please mail us. We carefully consider all comments and we especially like constructive criticism ;-)

Please mail us at support@frontbase.com if you need any assistance with this or any other issue.