Skip to main content
Known Participant
February 2, 2010
Question

SQL, recordsets and multiple table queries.

  • February 2, 2010
  • 3 replies
  • 2317 views

I have a table and a recordset containing the following SQL. which displays a members adverts if they have any offers or not. This works fine.

SELECT * FROM (

SELECT * FROM  advert LEFT JOIN offer ON advert.advert_id = offer.to)

a WHERE a.user_id = (SELECT members.user_id from members where members.username = sessionuser)

Basically the offers table contains an offers.from and an offers.to foreign key to the adverts parent table.

I can display the offers.to foreign key and link it to the advert table fine.

Now the problem I have is I need to link the offer.from foreign key to the advert table.

I created a 2nd recordset using a URL parameter offers.from. to access the adverts table again for the information (on a different record)

Although this works using the 'test' feature in the SQL dialogue box (in which the offer.from parameter is entered), when I run it nothing is displayed. I have even displayed offer.from in the table to make sure it is getting that value, which it is.

Is this because..........

                             I have chosen to display only records for the the users particular login in the 1st recordset.

                            recordset1 and recordset2 are not linked?

Any other suggestions.

This topic has been closed for replies.

3 replies

harkusaAuthor
Known Participant
February 2, 2010

I need an offers table because it contains information on the transaction between the two adverts.

E.g. status (open, complete etc) and date.

Participating Frequently
February 3, 2010

>I need an offers table because it contains

>information on the transaction between the two adverts.

Yes, I understand that. My questions were:

1) Why are you complicating things by using a derived table?

2) Why do you need two recordsets? Why not just pull all the data into a single recordset?

Participating Frequently
February 4, 2010

Sorry

Hope this looks a bit better

offered                            wanted                   offer

ID       o_make  o_model  w_make  w_model  ID advert o_make o_model

29       Gibson    LP            Fender     Strat          1  32         Fender   Strat

                                                                             33     Gibson   SG

30       PRS       Mira


OK, first of all I suspect that you could better normalize the design by either

1) Create a new table with a single column to store the item with a flag to indicate whether it is wanted or offered. The table would link to the advert and have a row for each advert/item combination, or

2) Create two tables; items_wanted and items_offered

I think either way would simplify this query, and probably more that you haven't thought of yet.

Regardless, your current issue is that you have a table with a many to many relationship with itself. That's not a problem. You are using the offer table to link the advert to itself. The problem is that you want to link the table to itself on two fields. Still, it's do-able. The two options here are whether you want all details on a single row. For example, if a advert has items wanted and items offered, do you want to display both corresponding offer details on the same row? Or, create two lines for each advert/offer combo - one for the wanted items and one for the offered items.

For the first, you need 5 tables. The original advert table and offer table, and another two aliases for advert and one alias for offer. The SQL would be something like:

SELECT advert.username, advert.o_make, advert.o_model, advert.w_make, advert.w_model, advert_1.o_make, advert_1.o_model, advert_2.w_make, advert_2.w_model, advert_1.username
FROM (((advert LEFT JOIN offer AS offer_1 ON advert.advert_id = offer_1.to) LEFT JOIN advert AS advert_1 ON offer_1.from = advert_1.advert_id) LEFT JOIN offer ON advert.advert_id = offer.from) LEFT JOIN advert AS advert_2 ON offer.to = advert_2.advert_id;

For the second option, you could create a union to list the items offered on one line and the items wanted on another line. The syntax between the two UNION queries would be similar, having the advert table outer joined to the offer table which is then outer joined again to an alias of the advert table. The only difference is the joins on the 'from' and 'to' would be reversed.

Participating Frequently
February 2, 2010

>I can display the offers.to foreign key and link it to the advert table fine.

>Now the problem I have is I need to link the offer.from foreign key to the advert table.

>I created a 2nd recordset using a URL parameter offers.from. to access the adverts table again for the information (on a different record)

Why do you need to create a 2nd recordset. Can't you just create a table alias for advert and join to the offers.from column?  Or do you need two recordsets for another reason?

Also, why are you using a derived table? I don't see a reason for it.

harkusaAuthor
Known Participant
February 2, 2010

To be honest I did try to do it like this but couldn't then select the binded objects in dreamweaver as the syntax was incorrect.

Is it possibe to have an INNER JOIN with an alias anyway?

In any case It would be better to go the SQL route.

Any suggestion on how the code would look?

Participating Frequently
February 3, 2010

>To be honest I did try to do it like this but

>couldn't then select the binded objects in

>dreamweaver as the syntax was incorrect.

OK, I'm not exactly sure what you tried, but one of your problems could be due to your use of Select *.  It's almost always better to explicitly state the list of columns you want. This is extemely important if you have two tables that share column names as they will be ambiguous. And if you are aliasing a second adverts table as I suggested, then you are guaranteed to have ambiguous columns so you need to list the columns explicitly.

harkusaAuthor
Known Participant
February 2, 2010

Well, it not a problem with the user login as I have changed the offers to be for the same user,just to eliminate this possibility

So it must be to do with the actual recordset

Any Suggestions