Bahut

Saturday, April 29, 2006

Firefox is terrible to install for administrators, or just people who install it often.

You cannot give arguments to the installer, so you are forced to click your way through the dialogs. The worst of these dialogs is obviously the braindead browse for folder dialog. No way to just type in the path where you want FF installed.

Then it creates a user profile, and there is no way to have that profile take some predefined settings from an .ini file, some existing profile folder or whatever. Profiles cannot be copied either, because they have these stupid paths like "C:\Documents and Settings\john\Application Data\Mozilla\Firefox\Profiles\uwayeoxn.default\" hardcoded into several of their files. (Why don't they use variables like %APPDATA% on Windows, $HOME, etc.?)

While the about:config page would probably allow entering all the needed settings, there is no way to automate or even simplify that. click click click...

The Bookmarks are pretty easy to configure, and the file can be copied. And userChrome.css can be copied too, but it should be possible to define defaults for these.

The real trouble starts with plugins and extensions...

The fact that the ShockWave installer is now bundled with some spy/ad/whatever-shit-ware (the Yahoo toolbar) is no fault of Firefox. But if it were possible to just copy an FF install where Shockwave was successfully installed while carefully avoiding the Yahoo trap, that would be nice.

Update: In fact, it is apparently possible to just copy the FF folder from one machine to another. That is very good. And the Flash player keeps working (not Shockwave, though).But this doesn't take care of all the settings and configuration, and still leaves problems with extensions.

Update2: For Flash, it seems pretty easy after all. I have yet to test it on an install on a new machine, but it seems that all is needed are the files Firefox-dir\plugins\NPSWF32.dlland Firefox-dir\plugins\NPSWF32_FlashUtil.exe. I used to have files in %SystemRoot%\System32\Macromed\Flash, but it seems to work without them.

Well, if you inadvertently used that stupid money type and need to convert, maybe the simple solution below will work for you. It takes advantage of the fact that you can use Perl in PostgreSQL functions.

(in case you are not familiar with Perl, here is what it does: assign the argument to the $_ variable; remove any characters which are not a digit, a dot or a minus sign; return the result multiplied by 1 to ensure it is numeric)

Thursday, April 06, 2006

English may not be one of the official Swiss languages (yet?), but it is certainly useful in a computer system. I don't want server logs and error messages in French or German or Italian (or Romantsch?). These things are easiest to understand and get help about in English. But I don't want dates in the confusing US "MM/DD/YY" format either, or times in AM/PM. Most importantly: I want sorting to work correctly with accented letters, and I want Perl to understand accented letters for \w, the uc(), lc() functions, etc.

So I made my own en_CH locale. Tested it in Debian stable (3.1 "Sarge"), and it seems to do what I expected. If you want to try it out, the steps are below. And it is quite easy to edit language_COUNTRY files to suit your needs.

You may also need to edit your /etc/environment file and/or /etc/default/locale if they have a left-over LANGUAGE= line.At your next login, your locale should be set to en_CH, and these little tests should work:

Monday, April 03, 2006

I like using PostgreSQL with an MS Access frontend for various little database applications, but always had trouble with boolean fields. Finally, after all sorts of tests, I think I nailed down what is needed to make it work, and avoid all these errors like "operator does not exist: boolean = integer", "Data Type mismatch in criteria expression", "invalid input syntax for type boolean: "-" (#7)", and another one which I can't remember.
What we want is simple:

Booleans should be usable in Access queries with simple statements like SELECT x FROM y WHERE z; (and no silly stuff like where z=true, z='t', z=-1 or the insane where cbool(z)=true)

Booleans should appear as check boxes in Access forms and tables

I still don't quite understand why this is not hanlded transparently by the ODBC driver, but anyway here is what seems to be needed with PostgreSQL 7.4:

After linking the tables in Access, if you want check boxes in table view, you need to go into table design mode. It will show an error because it's a linked table; just ignore it. Select your boolean field(s) and set their Lookup -> Display Control to Check Box.

I like using PostgreSQL with an MS Access frontend for various little database applications, but always had trouble with boolean fields. Finally, after all sorts of tests, I think I nailed down what is needed to make it work, and avoid all these errors like "operator does not exist: boolean = integer", "Data Type mismatch in criteria expression", "invalid input syntax for type boolean: "-" (#7)", and another one which I can't remember.
What we want is simple:

Booleans should be usable in Access queries with simple statements like SELECT x FROM y WHERE z; (and no silly stuff like where z=true, z='t', z=-1 or the insane where cbool(z)=true)

Booleans should appear as check boxes in Access forms and tables

I still don't quite understand why this is not hanlded transparently by the ODBC driver, but anyway here is what seems to be needed with PostgreSQL 7.4:

After linking the tables in Access, if you want check boxes in table view, you need to go into table design mode. It will show an error because it's a linked table; just ignore it. Select your boolean field(s) and set their Lookup -> Display Control to Check Box.