multiple database recordsets -- mdi app

Is it OK to have several instances of the same recordsets to perform different purposes in a database app?

Here's what I'm trying to do:

1.  Show all info 1 record at a time (from several related tables) in a view

2.  Allow users to browse each separate table & set filters to find various sets of records

SHould I create different recordsets in the document & give them to each view as they are needed?  SInce this is an MDI app, users can switch back & forth between windows at any time.

Also, does anyone have any generic filter-setting code?  Right now I have a hard-coded dialog for each table.  It seems redundant.  I'm wondering if there is a generic class that could read a table structure & present it to users for filtering.


Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

have you tried using m_strFilter before?
What Kind of Database Are you Using?
There is nothing wrong as far as U or any body using don't add or delete records to the table of which U are creating multiple instances.

U need not have an associated class for each filter U can query using SELCT statement like one below
CRecordset rs;
rs.Open("SELECT field1, field2, field3 FROM MyTable WHERE field1 > 100");

for which even U can use Filter to set and reopen the table or requery it and choose only selected fields of the table

Hope this helps
veronicasAuthor Commented:
The class I was talking about for the filter is one that will create a screen for the user with the various field names and allow them to create a filter string through a GUI.  I used to do this back in the days with Clipper, but I'm dating myself.  The code will read the field names, create a dialog for the users and allow them to enter values for selected fields.

Anyway, back to the original question.  In my document, I've got 3 recordsets, one for each table.  However, since the user could open a view to see the whole table, and possibly one to see a selected set of records, or possibly go back to the main screen and see a snapshot of the fields from the 3 tables all on one screen, I was wondering if I should also hold a temp recordset & give that out from the document as needed.
Yes you can do what you require, you can simply store the recordset and the filter in each doc, and handle the view updating as normal.

As for the filter you could create a totally generic sollution using the dao/ado methods to get field names and types.  I would be quite an interesting task.  Enumerate the fields for each table you want to allow viewing on, slap them onto a grid or other GUI and let the user enter suitable values.  Then contruct the SQL and put it into the m_strFilter.

Bosh, SQL just do it!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.