I'm trying to create unit tests for a function that uses database queries in its implementation. My understanding of unit testing is that you shouldn't be using outside resources such as databases for unit testing, and you should just create mock objects essentially hard coding the results of the queries.
However, in this case, the queries are implementation specific, and if the implementation would change, so would the queries. My understanding is also that unit testing is very useful because it essentially allows you to change the implementation of your code whenever you want while being sure it still works.
In this case, would it be better to create a database for testing purposes, or to make the testing tailored to this specific implementation and change the test code if we ever change the implementation?
As it seems I got the wrong end of the stick, I had a similarish problem and like you an ORM was not an option.
The way I addressed it was with simple collections of Data Transfer objects. 
So the new code I wrote, had no direct access to the db. It did everything with simple lists of objects. All the business logic and ui could be tested without the db.
Then I had an other module that did nothing but read and write to the db, to and from my collections of objects. It was a poor mans ORM basically, a lot of donkey work. 
Testing was run the db creation script, then some test helper code to populate the db with data I needed for each test.
Boring but effective, and you can with a bit of care, refactor it in to the code base without too much risk.
Unit testing on implementation-specific database usage