Keith,
I don't know what interface you are using to build your application,
but this sounds like a good case for a database abstraction layer. If
your interface language allows such a database abstraction layer
(Class::DBI in perl, PEAR DB in PHP, others in other languages), you
could almost certainly benefit from it. Then, your application need
only interact with the database abstraction layer, not the database
itself. You can, of course, move down a level and access the database
directly, but the point is that you don't need to most of the time.
So, what interface are you using to build your application?
Sean
On Jun 22, 2005, at 10:55 PM, Keith Worthington wrote:
> Hi All,
>
> I am working on an application that has a search dialog. The dialog
> is automatically populated with all of the available fields. It gets
> the field names from the views that were used on the form that the
> search dialog was launched from.
>
> The issue that is slowly getting unmanageable is handling the
> different data types. If it is a date do this, if it is a string do
> that and if it is a boolean do something else.
>
> I would like to remove this complexity from the application.
>
> I am hoping that there is a way given the view/column names that I can
> either
> 1) dynamically build the WHERE clause
> 2) dynamically build the whole query
> 3) dynamically build the whole query, run it and return the results
>
> Has anyone tried something like this before?
>
> --
> Kind Regards,
> Keith
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
