I’d like to thank everybody for participating. I appreciate the comments and suggestions.

I plan to leave REALbasic Gazette up for at least a little while. There may still be something here that somebody will find useful.

So, for most projects, you are going to probably want to create your database connection with “New REAL SQL Database”. The problem, though, is that although the database will be created for you if it doesn’t exist, it will be an empty database. You might imagine that if you designed a “New” database using REALbasic’s built-in database editor that somehow, magically, that same design would be created for you whenever a new database file is created. Sadly, that isn’t how it works. You will need to initialize newly created databases yourself.

How, you might wonder, can you determine if a database is newly created? One trick is to test for the existence of each table using the FieldSchema method. If you get an error, or you an empty RecordSet, then you can assume that the table doesn’t exist and create it.

If you are interested in the REAL SQL Database, then you might want to check this article out.

I have no doubt that I’m reinventing the wheel here. Other Preference classes surely exist. But it might be fun to do it all myself, rather than swipe what somebody else has written.

So, what is the big problem with reusing DatabaseRecords? Consider this example:

dim dr as new DatabaseRecord
dr.Column("a") = "hello"
db.InsertRecord "table1", dr
dr.Column("b") = "goodbye"
db.InsertRecord "table2", dr

Notice in the example that we use the same DatabaseRecord to insert a record first into “table1″ and then into “table2″. Before we insert the record into “table1″ we assign a value to the “a” field. And, before we insert the record into “table2″ we assign a value to the “b” field. The problem is that the value for the “a” field still exists in the DatabaseRecord when we insert it into “table2″. Now, if we are lucky, “table2″ doesn’t have a column called “a” and the worst thing that will happen is that we get an error for the second insert. But, if “table2″ has an “a” field, then we have just inserted a record into “table2″ with a value for “a” when it isn’t clear that that is what we meant to do.

If you are going to be inserting a number of records into the same table, and you are always going to be referring to the same columns, then it is probably acceptable to reuse a DatabaseRecord for every insert. But if you are mixing the columns, or if you are inserting records into different tables, then you really need to create a new DatabaseRecord for each insert.

Personally, I don’t think it is worth worrying about. So I always create a new DatabaseRecord for every insert. Which is why I cautioned against reusing DatabaseRecords in the previous post.

dim dr as new DatabaseRecord
dr.Column("category") = "tools"
db.InsertRecord "Categories", dr
dr = new DatabaseRecord
dr.Column("category") = "animals"
db.InsertRecord "Categories", dr
dr = new DatabaseRecord
dr.Column("category") = "colors"
db.InsertRecord "Categories", dr
dr = new DatabaseRecord
dr.Column("category") = "people"
db.InsertRecord "Categories", dr
db.Commit

I thought it might be cool to write a variant of InsertRecord that took arrays of values to insert, rather than a DatabaseRecord. So I did. It looks like this:

Sub InsertRecord(Extends aDatabase as Database, _
aTable as String, aHeaders() as String, aValues() as String)
dim dr as new DatabaseRecord
for i as Integer = 0 to Ubound(aHeaders)
dr.Column(aHeaders(i)) = aValues(i)
next

aDatabase.InsertRecord aTable, dr
if aDatabase.Error then
return
end if

aDatabase.Commit
End Sub

With this new InsertRecord, the inserts above look like this:

db.InsertRecord "Categories" Array("category"), Array("tools")
db.InsertRecord "Categories" Array("category"), Array("animals")
db.InsertRecord "Categories" Array("category"), Array("colors")
db.InsertRecord "Categories" Array("category"), Array("people")

That’s much cleaner. One thing to be aware of, though, is that the new InsertRecord only inserts String values. We could probably rewrite it to insert an array of Variants instead, but the String version is fine for what I need it for.

I’ve a plan to come up with more of these kinds of tricks and put them all together into a collection of modules and classes that can be imported into any Database application. I’ll try to provide more tricks like this as I come up with them. Then, when I’ve collected enough of them together, I’ll put the whole thing together as a download.

In order to understand what Release Builder does, you first have to understand the problem. As you know, a software release consists of some number of folders, each of which is filled with some number of files. The files that go into a release are probably created in various ways. Some of them are text files. Others are PDFs. Still others are the binary executables created with some software development tool such as REALbasic. There will certainly be other kinds of files as well, depending on the kind of software that is being released. In order to build the final release, it is necessary to create the three of folders that will be the release, and fill those folders with the various files that go in them. If the release is for multiple platforms, then you may need separate release trees for each platform. And the files in each tree may have further restrictions. For example, text files in the Mac OS release might need to have Mac line endings. but text files in the Windows release will need Windows line endings. Also, Mac files may need a type and creator set, while Windows files don’t.

Ideally a release tree would be something that is generated automatically. Many developers build scripts to generate a release. Scripts are cool, of course, but what I’d really like to have is a GUI tool that lets me build the release tree visually, and then lets me populate the tree with files on my hard drive. I’d be able to drag the items in the tree around to rearrange them. And I’d be able to drag files from my hard drive and drop them on folders in the release tree. Then the tool would automatically generate the release from the release tree I’d built. It would also take care of setting line endings and such automatically. There might even be a facility for using templates and scripts to generate some of the items in the release, but that feature would be strictly extra credit.

The utility I just described is Release Builder. There would be a place to create the tree of folders. Then, you would drag real files from your hard drive to the folders in the release tree. Once you have things the way you want them, you could save the whole thing to a file in order to use it again later. To build a release you would just choose your release target (Mac OS, Windows, or Linux) and the release would be built for you automatically.

I’ve left out a lot of details, but I think you get the general idea. I have no idea if this is a project I’ll actually be able to finish. But I know that if I could finish it, I’d use it a lot.

As soon as I’ve had a chance to add some tests to the suite, I’ll post some notes on how the process works. I’ve downloaded the project and it doesn’t look to be too hard. Basically, adding a new test (or group of tests) involves creating a new object that implements the Test interface. Then, to get the suite to include the new test, you have to add a line to the AllTests method found in the ListOfTests module. I’m not yet sure if that is all you have to do. I’ll try to report back when I have more information.

<http://realsoftware.com/feedback/viewreport.php?reportid=lvynuxhu>

Another bug has to do with default PushButtons. That would be PushButtons for which the Default property has been checked. For some reason, default PushButtons aren’t as tall as a regular PushButton of the same height. I think it might have something to do with the extra eye candy that gets displayed for a default PushButton. The workaround for this bug is to make the button taller. I actually have a PushButton subclass that automatically resizes itself in its Open event, depending on the platform on which it is running. I then use a constant, called ‘PushButtonHeightAdjustment’ with different values for each platform, that I use to calculate the new height. So, to work around this bug, I created another constant called ‘DefaultPushButtonHeightAdjustment’ that uses an even larger value for the height adjustment.

Anyway, if you are interested in this bug, the report is here:

<http://realsoftware.com/feedback/viewreport.php?reportid=yzpmgzba>