How to stop Access from "correcting" my queries? - ms-access

When I have subqueries in Access, it tries to 'correct' them without asking and breaks the query in the process. For example,
Select * from TblA LEFT JOIN (Select * from [TblB] union Select * from [TblC]) as SubQry On TblA.Whatever = SubQry.Whatever
This works fine when I run it the first time. However, after I save it and try to reopen it, Access tries to be 'helpful' and changes the parens to brackets:
Select * from TblA LEFT JOIN [Select * from [TblB] union Select * from [TblC]]. as SubQry On TblA.Whatever = SubQry.Whatever
Of course, this throws an error. Is there an option somewhere in the options menu I can toggle to make Access stop trying to 'help' me?
(Footnote: The actual table names are more complex than "TblB" and need to be in brackets to be recognized).

AFAIK, you can't. Parentheses aroud your subqueries are always changed to square brackets, and you have to revert this if you want to re-save.
All you could do is save the sub query as a separate query and use that one until you application is really stable, and then integrate the sub query in the main one.

Related

MySQL return no results from select * where varchar="" query

I'm having issue with my study project for creating database in MySQL.
I've imported data using LOAD to my created table from a CSV file. Now when I'm executing select * from mytable everything show up perfectly, but when I execute select * from bi_jogging.routes as r where r.Creator_Email="jhenderson7c#bbb.org"
I get nothing.
The email is there, I've tried different syntax options but it seems to be something else, I suspect something with the varchar format, I really have nothing in mind.
For other tables it works fine and others not.
You can try using the query:
select * from bi_jogging.routes as r where r.Creator_Email like "%jhenderson7c#bbb.org%"
If like operator shows the result then there may be white spaces in the email, please double check..
For join try this:
select * from bi_jogging.routes as r join bi_jogging.buddies as b
on b.Email like '%r.Creator_Email%'
I think it should work. Again check with same code.
select * from bi_jogging.routes as r where r.Creator_Email='jhenderson7c#bbb.org'
if [select * from mytable] this works ,then try to copy the email from result and paste it in where clause.
There may be conflicts between quotes.
your table entry contains quotes???
check properly. i think you have quotes in your table entry,so when you try this,
select * from bi_jogging.routes as r where r.Creator_Email like "%jhenderson7c#bbb.org%"
'%' sign matches with any character and you will get the result.
Inside the tablejhenderson7c#bbb.org and "jhenderson7c#bbb.org" are completely different.
I found spaces in the mysql tables after few emails, so I guess that was it. burned 8 hours on this one, thank you all. I could not find the spaces at the end of the mail by looking at it, I had to hit backspace to see that only after two hits the last char is deleted
this helped me : UPDATE bi_jogging.results set Mail_Found = TRIM(Replace(Replace(Replace(Mail_Found,'\t',''),'\n',''),'\r',''));

MySQL select selected columns plus all other columns on command line

It used to be that I could fire a query like the following in a query window/sql command line, against MS SQL server:
SELECT foo1, foo2, * from bar
Basically show the specified columns followed by rest of the columns. But MySQL does not allow this; throws back a syntax error at me. Is there an alternative syntax to do this in MySQL? Note that I am NOT trying to do this in code (where it has no practical use); I am using it for firing random queries against my DB to look up information.
Just declare the table on the SELECT CLAUSE.
SELECT foo1, foo2, bar.* from bar;
OR
SELECT b.foo1, b.foo2, b.* from bar b;
;-)
If you name the table (either by using the full name, or by using an alias like below), you can actually get it to work (tested for version 5.5.31)
SELECT b.foo1, b.foo2, b.* FROM bar b

Change order of MySQL query keywords?

I'm using this 3rd party report generating software. It has the following steps:
1) insert your SQL statement into a webpage.
2) invoke an API to send the a set of primary keys to the Query
3) A Report is generated.
Unfortunately, the software is dumb, and simply appends the WHERE clause after the SQL statement. However with MySQL the WHERE statement is supposed to be before the GROUP BY. So when the API appends a WHERE it fails because its invalid SQL. Is there some way to tell MySQL to expect the WHERE statement at the end?
select incident.incidentID,
GROUP_CONCAT(moccode2.Description) as MOC2Description
from incident
join incidentmoc on incident.IncidentID = incidentmoc.IncidentID
inner join moccode2 on moccode2.id = incidentmoc.moccodeid
/* WHERE should go here */
group by incident.incidentID
/* I want the WHERE to go here */
Derek Kromm is basically correct in what I asked for, unfortunately I have additional constraints. It's still going to append the WHERE.
So I tried this:
select incident.incidentID,
GROUP_CONCAT(moccode2.Description) as MOC2Description
from incident
join incidentmoc on incident.IncidentID = incidentmoc.IncidentID
inner join moccode2 on moccode2.id = incidentmoc.moccodeid
group by incident.incidentID
HAVING incident.IncidentID > 1
////////////////////////////////////////
now software appends WHERE invalid SQL
Use the HAVING keyword
This link has some details around using it: http://www.mysqltutorial.org/mysql-having.aspx

When using skip and take to page data, how can I get the total record count without a separate query?

I don't see how this is possible, but I really, really hate to run my query an extra time just to get the record count so I can build a pager. When I say a "pager" I simply mean the common gizmo with a link for each 10 records for example.
Assuming you are building a query in the selecting event, the best you could do is construct the full query, get and save the count, then take or skip it into the e.result.
And by best I mean, the easiest read code from a single query, rather than two. You'll still be running two separate evaluations on the database though. Use query analyser to see if the statements are a 'Select Count' then a 'Select take' or a dirty big select pared down by LINQ after the retrieve. I think LINQ does the former.
As far as I know it is not possible to return the total count and the items retrieved by skip and take at the same time.
I wrote a custom data source control and view, which caches the count for a short duration. I invalidate the cache whenever the criteria changes that would affect the number of results, but not when the data is paged, or when the data is sorted for instance.
I was concerned about this same question. Here is are the results of my experimenting in Linqpad--the actual behavior of Linq does not create a full new query to the SQL server:
This simple test, in one of my development databases:
var query = from p in HrPersons select p;
var x = query.Skip(20).Take(10).Dump();
var t = query.Count().Dump();
generates the following actual SQL queries:
SELECT [t1].[company] AS [Company], [t1].[processLevel] AS [ProcessLevel], [t1].[emplId] AS [EmplId], [t1].[sn] AS [Sn], [t1].[givenName] AS [GivenName], [t1].[middleInitial] AS [MiddleInitial], [t1].[nickName] AS [NickName], [t1].[formerName] AS [FormerName], [t1].[ssn] AS [Ssn], [t1].[cn] AS [Cn], [t1].[costCenter] AS [CostCenter], [t1].[title] AS [Title], [t1].[status] AS [Status], [t1].[batch] AS [Batch], [t1].[rowversion] AS [Rowversion], [t1].[id] AS [Id], [t1].[source] AS [Source]
FROM (
SELECT ROW_NUMBER() OVER (ORDER BY [t0].[company], [t0].[processLevel], [t0].[emplId], [t0].[sn], [t0].[givenName], [t0].[middleInitial], [t0].[nickName], [t0].[formerName], [t0].[ssn], [t0].[cn], [t0].[costCenter], [t0].[title], [t0].[status], [t0].[batch], [t0].[rowversion], [t0].[id], [t0].[source]) AS [ROW_NUMBER], [t0].[company], [t0].[processLevel], [t0].[emplId], [t0].[sn], [t0].[givenName], [t0].[middleInitial], [t0].[nickName], [t0].[formerName], [t0].[ssn], [t0].[cn], [t0].[costCenter], [t0].[title], [t0].[status], [t0].[batch], [t0].[rowversion], [t0].[id], [t0].[source]
FROM [HrPerson] AS [t0]
) AS [t1]
WHERE [t1].[ROW_NUMBER] BETWEEN #p0 + 1 AND #p0 + #p1
ORDER BY [t1].[ROW_NUMBER]
GO
SELECT COUNT(*) AS [value]
FROM [HrPerson] AS [t0]
So while there is a second SQL query, it is a trivial one that only requests the total count. I believe this is reasonable and acceptable as a pattern.

MySQL developer here -- Nesting with select * finicky in Oracle 10g?

I'm writing a simple diagnostic query then attempting to execute it in the Oracle 10g SQL Scratchpad. EDIT: It will not be used in code. I'm nesting a simple "Select *" and it's giving me errors.
In the SQL Scratchpad for Oracle 10g Enterprise Manager Console, this statement runs fine.
SELECT * FROM v$session sess, v$sql sql WHERE sql.sql_id(+) = sess.sql_id and sql.sql_text <> ' '
If I try to wrap that up in Select * from () tb2 I get an error, "ORA-00918: Column Ambiguously Defined". I didn't think that could ever happen with this kind of statement so I am a bit confused.
select * from
(SELECT * FROM v$session sess, v$sql sql WHERE sql.sql_id(+) = sess.sql_id and sql.sql_text <> ' ')
tb2
You should always be able to select * from the result set of another select * statement using this structure as far as I'm aware... right?
Is Oracle/10g/the scratchpad trying to force me to accept a certain syntactic structure to prevent excessive nesting? Is this a bug in scratchpad or something about how oracle works?
When Oracle parses a SELECT *, it expands it out to an actual list of the columns to be selected. Since your inline view contains two columns named SQL_ID, this results in an ambiguous reference.
Interestingly, using ANSI join syntax seems to cause it to alias the duplicate column names automatically, and therefore avoids the error.
select * from
(select * from v$session sess left outer join v$sql sql on sql.sql_id=sess.sql_id and sql.sql_text <> ' ')
Incidentally, it's not clear to me why you chose that condition on sql_text. I don't expect that column would ever contain a single space. Are you really trying to filter out NULLs? If so, why use an outer join at all?
One of the general rules of thumbs at my place of employment is that SELECT * is never allowed. Explicitly define what columns you need; not only is it more readable, but less likely to have issues down the road