Quote Originally Posted by rangudu_2008
1. What do u mean by limiting the no. of joins? Can u explain it in detail?
First I tell what I mean by JOIN. For me a JOIN is a connection between any two tables. If I connect 3 tables, that is 2 joins: One between tables A and B, and one between A and C. (Or B and C).

By limiting the number of joins I mean restricting these connections (essentially restricting the number connected tables) to a certain value. E.g. not allowing the user to join more than 4 tables.

2. If the join structure of a database is linear, how can any saved join be used? I meant to ask, how can a join be built using a join that is temporarily saved?
I'm not sure I understand the question. I'm trying my best to answer.

By "linear" I mean that between the tables there is no loop. (Or cycle or circular reference or whatever it is called. I'm sorry, I don't know the right words, even in my own language.)
By this definition, the letter 'X' is linear. The letter 'A' is not. You start walking at the very top of 'A' , and can get back to the same spot without ever turning back. It means there is a loop in the letter 'A'. And that loop is the upper triangle. In letter 'X' there's no loop. A query builder must check whether or not the joins defined by the user make a loop.

Now. In Access query builder the user has a nice graphical interface where they can display all the tables and joins they want. But with your form, the user can select and display only one join, and two tables at a time. I tried to imagine how multiple joins can be created this way, and came up with the idea that these join definitions should be temporarily saved, one by one, in a properly designed array variable, or collection, or something. This way the user defines all the joins they want, without any actual change made to the database. When they have finished, they click on a [Build Query] button. And then the code iterates through the saved join definitions, and builds the "FROM" clause of the SQL.

How did you plan to do it?

3. I get ur idea in using graph theory for that algo, but if joins can be saved (temporarily) to the database, how can they be used to build the required query?
I think this was covered in Answer #2. But to make it more clear, I didn't propose to save the joins to the batabase, even temporarily. I proposed to save their definitions to an array or collection. (By the way, have you seen the update to my previous post? )

I feel this idea getting crystallized. How is it with you?
I think the next step (or substep) would be discovering the best way to (temporarily) store these join definitions.

Do u get any ideas from that flash demo that i attached earlier?
Yes, I did. One was the criteria builder that even OBP marked as excellent. Another example was using Acwzmain to obtain a unique query name. There were some others, but right now I can't recall them. Why do you ask?

Jimmy