You'll need to tell us why it is "not an option". There's a reason for using date fields for dates instead of text and performing find for a specified date or all dates in a specified range is one of those reasons.
I suspect that we can come up with a restructured approach that puts those dates into date fields, but still gives you what you need in that text field. (Another really big reason for not entering dates into a text field is that it becomes possible to enter impossible dates such as 31/02/2012.)
The option to use a text feild is that there are some invalid and incomplete dates being entered. The database keeps Research, some research records dating back to the 1700s and 1800s and date formats and info vary. Dates have been entered as '1886' only, or 'May 1886', '5/1886', '1st August 1785', ' even 'Not Known'. Each user has their own date format preference in line with thier research requirements. The other reason is there are a large number of current users of the database, with records totaling over 3000. Too late to change?
Not too late to change but there is a need to describe what type of searches of this data you want to do.
If these are two separate text fields, a calculation field can be defined that translates any valid, but incomplete dates into an actual date. The large number of date format preferences will make this very difficult to produce dates that work for all users.
I strongly recommend you transition to an inteface that requires users to enter valid data in a consistent format.
One example would be three text fields where the users enter month, day and year in separate text fields. A year would be required, but month and day fields could be left blank.