Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The other answers have correctly pointed out the missing <code>from</code> keyword and the wrong order of the <code>group by</code> and <code>order by</code> clauses. There should be no problem about following the advice you got there.</p> <p>One other thing is the syntax you are using to join the tables. Although technically not a mistake, it is considered outdated. The newer standard offers dedicated keywords for joining, which lets you separate your joining logic from your filtering-by-values logic, which previously, as per the older standard, had to be mixed in one clause, the <code>WHERE</code> clause.</p> <p>Let me show this by rewriting the <code>FROM</code> and <code>WHERE</code> clauses for you, so you can see the difference. First, here's your current join logic implementation:</p> <pre><code>FROM serialNumber_tbl AS sn, Entitlement_tbl AS ent, Company_tbl AS c WHERE sn.serialNumberId = ent.serialNumberId AND c.companyId = sn.companyId </code></pre> <p>Both conditions in the <code>WHERE</code> clause are join conditions. Here's how the same fragment of code changes when done with the newer syntax:</p> <pre><code>FROM serialNumber_tbl AS sn INNER JOIN Entitlement_tbl AS ent ON sn.serialNumberId = ent.serialNumberId INNER JOIN Company_tbl AS c ON c.companyId = sn.companyId </code></pre> <p>In this case the <code>WHERE</code> clause is gone entirely, of course, but you shouldn't have the wrong impression that it is always like that. Generally the <code>WHERE</code> clause remains valid and useful. If it contained some other conditions that were not part of the joining logic, they would retain there places in the <code>WHERE</code> clause. I'm talking about conditions like <code>ent.Date &lt; '19900101' AND c.CompanyName NOT IN ('IBM', 'Microsoft')</code>.</p> <p>Like I said earlier, with the older syntax, which you are using presently, that condition would be in one clause with the join conditions. In simpler cases, like yours, it might be overlooked without problems, but in more complex queries it could become an issue, if not a nightmare, in terms of maintainability. So the point is to get used to the newer syntax before you start writing such complex queries.</p>
    singulars
    1. This table or related slice is empty.
    1. POHelp construct a query (schema provided)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAndriy M
    1. USAndriy M
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks! I learned something new =)
      singulars
      1. PO
      1. USDonut
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload