Angus Thinks…

Oracle connectivity has been one of the main things I’ve been working on this week with SQLEditor. This involved installing Oracle on my iBook. Oracle 10g is a remarkably complicated bit of software. It arrives in a 500MB+ download which takes forever to download and then a significant amount of time to install.

My machine is also noticably short of memory for oracle because it has only 256MB of ram, rather than the 512MB recommended.

The good news is that simple databases are now accessible using oracle, although larger ones are still a bit too big. I’m still working on trying to fix this. The idea of schemas in Oracle is also quite different in that you pretty much use one database and then sub-divide it up.

I’ve added a nice about box to the application that now includes a two column credits section and details of the username and serial number for the application.

After a rather over-extended development cycle SQLEditor version 1.0 has now been released. Which is a great relief to me. I’ve been working on it for so long now that I can’t quite remember not working on it, which is weird. Admittedly that’s only really about 12 months, but still, it’s a significant portion of my life. It’s also the first major product I’ve released.

In a moment of commercialism I would encourage you to buy a copy because it makes a wonderful christmas gift, or at least it might if the recipient really loved databases or if it was some other kind of program altogether. As it is, it probably wouldn’t make much of a Christmas gift. Socks or bottles of wine would be a better choice for almost anyone.

Releasing SQLEditor isn’t the end of the situation though. Version 1.1 is already being planned and I’ve various other projects that I’m working on as well, but SQLEditor is first and will always be the first piece of software that I released for sale.

Releasing software is complicated. In addition to the actual program, there is the distribution package, online help, the website, notifications to trackers like MacUpdate and Versiontracker, plus checking the online store is working correctly. Bad news with this release for anyone hoping for the pre-release discount. With the release of version 1.0 the offer expired.

People keep talking about MacPAD but nothing seems to be happening at the moment, only MacShareware.net seems to be supporting it (which is logical, since the two are quite closely tied together). I’ve got a MacPAD file up now, but nothing much else. I haven’t integrated it with the release managment stuff I’ve written (a motley collection of php and make files with a bit of XML for good measure).

If there was any market in it there is an interesting opportunity for a release management system (written perhaps in java?) that could generate everything automatically. Perhaps if I get really bored at some point I might do that.

The next step is to write a press release and send it out today. Joy

So, in conclusion, if you haven’t already tried SQLEditor, then version 1.0 will improve your life so much that you won’t know how you got by without it. Or at least might save some time when designing SQL databases.

Oddly enough the java.io.FileWriter class doesn’t use UTF-8 by default. I’m not exactly sure what the default encoding is (possibly ISO-8859-1 or US-ASCII?) but it doesn’t seem to be UTF-8, which is odd given that java strings are supposed to be unicode. This causes a problem if you want to have non-ascii characters and you don’t realise what’s happening. This was a bug in SQLEditor and somebody accidentally typed an umlaut into one of the fields and the file wouldn’t reload. (Which was annoying).

The correct thing to do seems to be to use the following:

OutputStreamWriter out = new OutputStreamWriter(new FileOutputStream(path),"UTF-8");

Which ensures that you are using UTF-8.

I suppose that the motivation for this is that it means that simple use of FileWriter is compatible with applications that are not unicode aware and don’t support UTF-8. It probably makes sense at some level, but it just goes to show that you can’t assume anything.

Unfortunately there was a crashing bug in SQLEditor beta 11 and I had to release b11a.

It was one of these things were format strings caused the crash. I’d transposed two of the entries

[NSString stringWithFormat:@" %@ %d",aDecimal,aString]

instead of

[NSString stringWithFormat:@" %@ %d", aString, aDecimal]

and of course cocoa crashed, probably because it tried to send a message to the aDecimal variable.

It’s unfortunate that this can’t be detected at compile time, because it’s really annoying and very easy to do.

Possibly this could be caught in an exception handler of some kind though. I’ll have to do some more work on it.

Lots of fun new features in SQLEditor Beta 9.

I think SQLEditor is getting quite close to the final release version actually, which is good.

I have set up a new bug reporting and tracking system.

I’ve been working recently on integrating a registration system into SQLEditor (sorry).

Unfortunately I kind of need to make some money out of my software and so people have to pay for it. I really wish this wasn’t the case but sadly it is.

So I now have an online store powered by swreg. If you visit the SQLEditor page you will now see a couple of purchasing options in the right column and further options are an a subsequent screen. It looks fairly close to the rest of the site and swreg offers better fraud prevention than paypal, particularly for credit cards.

The complexities of integrating everything together are quite great, which suprised me a bit. I was hoping for something easy, but it required a lot of steps to get everything pretty much working.

• Sign up to online store
• Add products
• Create templates for shopping basket
• Create serial number system
• integrate serial number system into application and online store

Although I won’t need to do this for any future software that I develop. Most of it was a one-off cost.

One oddity is that the serial number code is written in ANSI C. This is a bit odd, because most of the code that I have been writing recently has been either Objective C, Java or PHP. But ANSI C proved to be the best way of using the same codebase for both the server and client side components.

Hopefully lots of people will love and therefore buy the licenses.

I’ve recently been trying to write a serial number system for SQLEditor. I’m also looking for a new name for it. It was pointed out that the current name is generic and difficulty to pronounce, plus there is already at least one other “SQLEditor” out there already. Suggestions are welcome!

But back to the serial number thing. If I could remember more of the maths that I learnt at university I would be happier, but as I tend to do I had forgotten most of the stuff that I don’t use, retaining only the bits I do use (Vectors primarily, plus some other stuff).

Obviously serial number values end up in base 36 (0-9, A-Z), but other than that the problem occurred on how exactly to represent them. I need to have a link between the username and the serial number because that’s one of the methods implemented to discourage copying. If you see someone else’s name on the thing.

I’m currently looking at a graphic convertor like delay (it will wait 20 or 30 seconds at startup after the trial period is ended) rather than a complete lockout. Because I think (a) it’s nicer to do it that way and (b) it offers people a chance to experience the feature set even after 30 days have expired.

One thing I have noticed is that there are very few descriptions of how serial number systems actually work, probably to prevent people reverse engineering them and creating generators.

Of course the most secure system is one that receives a license key directly from a server, but I think that could be too intrusive. I guess we’ll see how well the first version works out.

New features for Beta 7 include “crows-feet” style referential cardinality indication and a new way of exporting foreign keys; following a suggestion they will be placed after the tables as soon as I write the code anyway, the parser is already capable, but the exporter is not.

Finally Beta 7 will also offer selectable colors on the fields, more transparency and prettier connector drawing. Possibly also table type for mysql as well as a new export system for creating databases via scripts on remote servers. More later.

SQLEditor Cocoa Beta 6 has been released. Beta 6 offers a number of significant enhancements and improvements, plus several bug fixes.

• Fields can now be dragged from one table to another.
• The list of data types can now be edited and changed
• Improved preferences options
• Better printing, including scaling, tiling and fit to page.
• New buttons to add a sibling field to a table or delete the currently inspected one
• C-shaped connectors are back. (This is where a connector loops back on itself if it would otherwise overlap either the source or destination field)
• You can now change the colors of objects. This is a global setting at the moment. Individual color changing is coming soon
• A few minor bug fixes
• Slightly altered the appearance of the table object view
• First version of online help. As yet incomplete.

This new version expires on September 30th 2004.

Why not download it now?

SQLEditorCB6.dmg[355k]

I just realised that NSLog allows parameters. I’d previously been using

NSLog([NSString stringWithFormat:@"%d",randomVar]) …

But now I realise that the I don’t really need to do this. A simple call to NSLog will work as well.

NSLog(@"%d",randomVar);

It still isn’t as easy as php or even java, but it’s shorter and tidier and so better.

Good news everyone!

SQLEditor Cocoa version is finally available for download.

SQLEditor Cocoa offers a Mac OS X native cocoa interface, an improved SQL parser, better performance and some bug fixes.

Download (325k)

Not much posting recently. But I’ve been working getting SQLEditor ready for release. The big things recently have been bug fixes and developing a serial number system.

It’s extremely annoying to have to spend any time at all working on the serial number system, because really the time would be better spent actually improving the software. But given that I actually want people to buy copies of the thing it is sadly necessary.

I have a simple test program working already and as soon as I develop some kind of key generator system I’ll be able to add it (probably to beta 6).

Beta 5 is complete, so it should be released tomorrow.

Good progress is being made again on the Cocoa version of SQLEditor. I have recently rewritten the parsing system to use javacc instead of my own home built parser. This allows for better, simpler and more reliable parsing. Writing my own parser was interesting but wasn’t really the best strategy. This new parser should make its way into the java version of SQLEditor eventually.
A key new feature is that the import system can now report parsing errors to the user. Previously the whole thing just kind of gave up without any indication of what went wrong. BAD!
Now you get a nice little window (actually a panel) that appears and gives a list of errors. The current development version always shows this window but I’m still trying to decide if it is better to show it on every import or just when something goes wrong.
The new parser is also much easier to expand to support new features. The old version required a complicated system to add new tokens, the new one has a standard format and requires only a single line.
The new version should also work reliably on Mac OS X 10.2 or Mac OS X 10.3. Which is a change over the previous version that crashed oddly on 10.3.

I’ve decided to release a new version of SQLEditor (Java). The FC1 version is a final candidate version that hopefully incorporates fixes for the bugs that people have reported. There have been problems with users running Mac OS X 10.3 because of crashes in the Java Virtual Machine. These are problems that Apple has to deal with and hopefully any remaining crashes will be fixed in revisions to the Apple JVM.

SQLEditorFC1.dmg

Well, I feel much better today. I’ve thought about it a bit more and I realise how very lucky I was that I found about the bug before the thing got a public release. I’m already working on some ideas on how to fix it. More on that as I think it up.

This really shows the importance of testing stuff. So thank you to everyone who has tried SQLEditor in its various versions.

Yet again the fact that I’m developing on Mac OS X 10.2.8 is causing problems. Bruce tried out a copy of SQLEditor (Cocoa) on 10.3 (Panther) and it doesn’t seem to work at all. You can’t seem to add objects to the canvas which is the key requirement. Most of the other functionality is based on this particular activity. I’ve looked quite carefully at the code and I really can’t see where the problem is. There isn’t anything odd going on.

This is really bad news, especially after the previous problems that occurred with the java version on 10.3 (which was the reason I wrote a cocoa version in the first place). I’m really not sure what to do.

This has made me a bit depressed because I’ve been working really hard on SQLEditor recently to prepare it for release.

It’s really annoying that there isn’t better compatibility between Mac OS X versions.

I’ll try to write some more about what I’m going to do about this tomorrow.

Yes, I know I said Sunday or Monday for the new beta. But instead I’ve been fixing more bugs and various things. So it should be better. There is now a new way of showing foreign key links which adds shading to the source and destination of the link. There is also an option to disable internet version checking and a new facility that catches connection failures so you don’t keep getting error messages if there is no internet connection available at all.

So the new beta version is coming soon, really it is, honest. Really and truly.

Punkish made the suggestion in one of the comments (actually the only comment) back on May 29th about adding an actual database to SQLEditor and turning it into a database program. The more I think about this the more I like the idea so it may end up happening. Although it will be a separate program from SQLEditor. SQLEditor will continue as it is because I need it that way for various projects myself.

BTW: The new cocoa version of SQLEditor is about to be released into public beta. Probably either today (Sunday) or tomorrow (Monday).

One thing that is desperately obvious when rewriting a java application to cocoa is overlapping views. In java you can often overlap swing components as long as they are lightweight (not operating system controls for instance). The cocoa documentation says that you shouldn’t overlap view components. This presents something of a problem obviously. How do you make such a significant change?

Currently SQLEditor uses NSViews for it’s onscreen rendering, however since the tables and comments can be freely dragged around there are three possibilities:

1. Use overlapping views and hope that nothing serious happens
2. Don’t allow views to overlap by restricting the ability of the user to drag them around
3. Rewrite the display code to use some other class instead of NSView and render the objects by hand

I’m still thinking about the best way of doing this. (1) is the current solution, I don’t like (2) and (3) looks like lots of work.

I think the best plan is to find out if (1) works on 10.3 and go from there. One approach that I am seriously considering is to rewrite the container class instead and continue to use NSView subclasses for the subcontainers.

SQLEditor Cocoa Beta 3 is making good progress. The only things remaining for the current beta are:

• Finish the menu handing
• Write some help

It now pretty much supports importing java version saved files although it’s still having trouble with foreign key support. Which is annoying me a bit but I think the current stage is reasonable to go on with until I can devote a bit more time to it.

Next step is probably to look at implementing more SQL structures and improve compatibility with the standard. I’m particularly interested in developing view support.

David was commenting that drag and drop from the java version of SQLEditor was handy, so it’s returned!
I implemented a new floating window which allows the user to drag and drop objects onto the main canvas. Which seems to work quite well. It doesn’t replace the existing menu options but it provides an easy and intuitive way to add objects. At least I hope it does…