jadamski

FIRST give every table in the JOIN an alias SELECT foo FROM Message M1 <-- 'M1' is the aliased name of the table JOIN Message M2 <-- again, aliasing the message table, now as 'M2' ON M1.PostID = M2.ParentPostID WHERE M1.blah or M2.blah SECOND Make sure your order of tables is correct. The highest detail in the last join. The next highest then finally the parent. In the example above M1 is parent. THIRD. Place your :WHERE condition in the right level.... In the M2 for just the detail. In the M1 for everything M1 did. Reorganize yours and see what happens..I suggest t1 t then tr. Try it and see!

What happens if you set the variable before that stored procedure and pass that variable by reference rather than value. It seems like you should be able to populate an array that way if you want to return a kind of set or list.

<< When transaction is done, a 'invoice sale' for example. It puts two records into the << database one for the 'invoice sale' and one for the product (coke). They have NOTHING << that matches up, except the price, but in that table there are 100 of things with that << price. It seems that something is missing here....most transaction database use line items to record detail and do summary posting elsewhere like in a sales journal or a general journal that is used to post monthly totals to a chart of accounts. An "Invoice Sale" sounds like the parent to a detail table of some kind. Are you sure you don't have a line items table in this database?

http://en.wikipedia.org/wiki/Software_development_process I don't know if this will help you specifically but here's how I would approach the problem. What kind of testing environment, implementation plan etc. really depends on you and the model or style of development you work under most of the time. Are you a single developer, or are you on a team? Do you have to report to anyone or do you develop for yourself. A good web application usually has three parts the UI, Platform and Database; so are you testing all three or just one part? What I recommend is to spend time on the WIKI's until you see yourself reflected in the advice there. Once you see your style and the tools you use being mentioned, latch on to that topic as a possible work method for you. Start with the general link above which about the entire process. Investigate what appears in the right hand column on most of the wiki pages. Those are links to the more specific subject matter. Make a note when a reference or process is like the situation you are working in. You didn't mention your tools etc, so I am assuming the LAMP stack. SVC is only one player in the Version Control universe so look at some others for simplicity. If you are an Eclipse user, you should tag what ever is Eclipse related until you can see a pattern emerging (likewise for Netbeans, Visual Studio, whatever). I teach this stuff and its what I try to get my students to do. Development is not done in a vacuum and every thing about it depends on you and the way in which you do your work. Try the wikis from the top and I think you will start to see what I mean.