What's the best way...

[Yazster]

I'm currently developing an ActiveX control designed to provide access to a specific database and perform various queries. The purpose of this is to provide our developers with the ability to perform queries without having to worry about SQL queries and such.

My database connects when the DatabaseName property is populated, and I use an enumeration to provide all the available types of queries.

My question really concerns the enumeration. My database has 13 fields and I currently have 19 different options in my enumeration. I find this is a lot and see this list potentially growing. There are so many combinations of fields that could be used to perform queries that I see the enumeration getting out of hand.

However, my control works extremely well and is very easy to use. Everyone is happy with it but I was just wondering if there was a better way of doing it.

Anybody have any ideas?

Thanks,
Yazster

 

[MatsHulten]

You could store each query in a separate file and then program a class that accesses and returns the query stored in the file, based on the file name.

-Mats Hulten

 

[Yazster]

That sounds like a possibility, but wouldn't the end result be the same? I mean when a programmer is accessing my class object, I still need an enumeration to present the possible choices don't I?

 

[listener22]

How about teaching your developers some sql?
After all, under your current scheme, if you were to leave,
no one would know how to maintain/expand your control. Jim

oracle, vb

 

[Yazster]

Our developers do know SQL to a certain extent. The goal is to increase code-reusability and cut-down on production time. By using pre-existing components, our developers can focus on other parts of the project rather than the database-related aspects.

I've been looking at some three-tier concepts and this seems to be the direction I'm trying to go in. However from what I've seen, production time in this type of design is significantly increased. To be honest, I'm not really familiar with this concept and I'm trying to do a little research on it.

 

[listener22]

Usually 3-tier means that the data tier creates sql statements
on the fly, based on requests passed to it from the (business) logic
tier, which in turn received a request from the UI. Generally speaking,
the UI allows the user to make limited queries of and limited changes to
the data, but not directly, only through the other 2 tiers. If you want
the user to be able to query on a number of fields, and not others,
on the UI, the UI should be able to pass the values in the filled-in textboxes
to the logic tier, where validation of those values occur, and the logic
tier passes them on to the data tier, where programmatically a sql
select statement is generated and passed to the database. (The data tier,
or the business logic tier, fills in wild cards for the textboxes left blank.)
There shouldn't be a need for 27 canned sql statements for different
combinations of the fields. Jim

oracle, vb