fork() support under Win32 is still very experimental, as Win32 does not support forking natively. The current implementation of fork() does mostly copy the whole data section of the current process and starts it as a second process as far as I know. This means that you will have an issue with all kinds of handles that are not directly supported by Win32 for inter-process sharing. File handles and socket handles are inheritable by child processes, but ODBC handles are not (or so it seems in your case).
It seems you have two possibilities now, either do away with fork() or do away with Win32::ODBC.
To do away with fork(), you could write yourself a server process that works as a database server and holds one ODBC handle open. But you'd then have to do asynchronous ODBC accesses and have an event driven server, both of which are hard to implement. Perl threads would maybe help a bit with the asynchronous ODBC accesses, but I don't even know whether ODBC allows more than one running query per connection.
To do away with Win32::ODBC, you could switch to MS SQL server or mySQL, both of which have Perl modules availabe for them, and as both of the connectors work via sockets (as far as I remember), you even might be able to inherit them via fork().