A fix

In my last post I told my fellow devs they should push the DBX-crap of the year to the side and just write your own wrapper.

But naturally, it was still itching as I even got a MS-SQL db connection to work. And it seems to be surprisingly easy: DBX wants MySQL4, and we’ll give it to him. With a DLL from the good ol’ mysql server 4.0 installation DBX will be fooled in a false sense of ease while you secretly have a connection to you MySQL 5 server.

Question is; how long is this going to last, at what point is it going to crack into a ‘ohno I got something unexpected from the server’-panic situation. Well, we’ll see.

Delphi 2007/2009 MySQL Madness

So I recently purchased Delphi 2009, and I have been working with Delphi 2007 occasionally elsewhere, and as always the third party libraries like Indy and DBX are as messy as can be.

Indy is never up to date (plus you keep writing thread-wrappers around the functions), and DBX contains a MySQL driver that doesn’t support MySQL 5.0 and up for some reason. With DBX you can insert, create, update and delete all you want – but a select query is too much for the library. When you select more than 1 field, using either * or the fieldnames, you get a nice access violation when you open the query. Don’t ask me why it does that, because it makes no sense whatsoever since No functions concerning queries, fields and values have changed since MySQL 4 (perhaps even earlier).

So we try to look up some other Delphi/Object Pascal libraries to work with MySQL. A simple rewrite of the C-API header files comes to mind (happily named mysql.pas) that dates from 2002. There are however a few hickups; Delphi 2009’s PChar is a PWideChar by default now. And honestly, who needs 2 byte chars when there’s a little thing called UTF-8. So that and some other stuff makes it quite annoying to adapt it.

And no, we’re not going to use the MySQL ODBC driver, because ODBC is the most useless system ever since you need to configure it on every client if you want to use it. I know that some people would like to believe Databases should only be run locally with fancy internetworking interfaces like SOAP or a custom thing, but sometimes that’s just not worth the trouble.

So what do we do when we are faced with overpriced libraries and useless alternatives? We write our own DLL in C/C++, define an easy to use interface, and dynamically link it against your application with a simple Delphi file.

Here’s a simple version to demonstrate it’s not rocket science.

ps. to create a valid lib to link against with MingW (instead of the default MSVC lib files that MySQL comes with), from the mysql\lib\opt directory type:

• prompt:> [yourmingwdir]\reimp -d libmysql.lib
• prompt:> [yourmingwdir]\dlltool -k -A -C -d libmysql.def -l libmysql.a

Another fix is to install the mysql version 4 dll libraries from the mysql.com website, but who knows what that kind of errors will produce in the longrun…

Cisco IOS DHCP Manual bindings for dummies

So I was screaming and ranting (not really, but dramatic effect always works… right?… what?.. it doesn’t? hmm…)

I use a Cisco 385 router (or is it 580, 850, 857, I can’t remember) to keep my network together and connect it to the outside world. It does a great job at most trivial things (except for IPv6 which is non-existant, and thus it will soon be replaced by a 1841 probably) and I have fun forwarding ports and whatnot.

The thing that however puzzled me was the fact that manual IP/DHCP bindings for computers in my local network were sometimes accepted, and sometimes not. I had “read” (as in read fast and inaccurate) the manual and came up with simple entries like:

ip dhcp pool afancyname
host 192.168.0.10 255.255.255.0
hardware-address 0012.3456.789a
client-name afancyname

And after fiddling around with settings in Windows for weeks, I finally started actually reading the manual and stumbled upon the difference between “hardware-address” and “client-identifier”.

The big difference (next to a simple 01 prefix to the mac-address) is that hardware-address is for BOOTP, and client-identifier is for DHCP. Client-Name is also BOOTP only, and should not be used.

So I looked up the Client-identifier via “sh ip dhcp bindings” and wrote the following config bit instead:

ip dhcp pool afancyname
host 192.168.0.10 255.255.255.0
client-identifier 0100.1234.5678.9a

Et voila, release and renew your IP address client-side, and you have your preferred IP address.

However, ofcourse this is only because Windows supplies the client-identifier argument with its DHCPRequest packet, and Linux for some reason does not. So for Linux hardware we need to fallback on hardware-address (unless you manually edited your dhclient.conf file it seems):

ip dhcp pool myfancylinuxpc
host 192.168.0.11 255.255.255.0
hardware-address 0012.3456.789b