I have a union query that pulls together data from a couple other queries. These queries search for data based on the date that is entered on a form.
I have been using this query for the longest time, and even have backups of this from months ago, when I know it worked, but suddenly, this error pops up instead.
The Union Query
SELECT MnthlyFireExCnt.ProjectCriteria AS Project, MnthlyFireExCnt.CountOfFire_Extinguisher_Location_ID_ AS NumberOf, MnthlyFireExCnt.Type
FROM MnthlyFireExCnt
UNION ALL
SELECT MnthlyFrstAdCnt.ProjectCriteria, MnthlyFrstAdCnt.CountOfForm_Record_Number, MnthlyFrstAdCnt.Type
FROM MnthlyFrstAdCnt
UNION ALL
SELECT MnthlyIncCnt.ProjectCriteria, MnthlyIncCnt.CountOfDate_Time_Reported, MnthlyIncCnt.Occurrence
FROM MnthlyIncCnt
UNION ALL
SELECT MnthlyJHACnt.ProjectCriteria, MnthlyJHACnt.CountOfDate, MnthlyJHACnt.Type
FROM MnthlyJHACnt
UNION ALL
SELECT MnthlySiteObsvCnt.ProjectCriteria, MnthlySiteObsvCnt.CountOfTime, MnthlySiteObsvCnt.Type
FROM MnthlySiteObsvCnt
UNION ALL
SELECT MnthlySSICnt.ProjectCriteria, MnthlySSICnt.CountOfDate, MnthlySSICnt.InspCriteria
FROM MnthlySSICnt
UNION ALL
SELECT MnthlyToolTCnt.ProjectCriteria, MnthlyToolTCnt.CountOfDate_Time, MnthlyToolTCnt.Type
FROM MnthlyToolTCnt
UNION ALL SELECT MnthlyWSSCnt.ProjectCriteria, MnthlyWSSCnt.CountOfForm_Record_Number, MnthlyWSSCnt.Type
FROM MnthlyWSSCnt;
And this is one of the query that pulls the data together for the Union Quer.
SELECT SSIReportsProjectCrit.ProjectCriteria, Count(MnthlyFireExData.Fire_Extinguisher_Location_ID_) AS CountOfFire_Extinguisher_Location_ID_, "Fire Extinguisher(s) Inspected" AS Type
FROM SSIReportsProjectCrit LEFT JOIN MnthlyFireExData ON SSIReportsProjectCrit.ProjectCriteria = MnthlyFireExData.Site_Location
GROUP BY SSIReportsProjectCrit.ProjectCriteria, "Fire Extinguisher(s) Inspected";
This query works no problem. It is pulling up the data.
Any help would be extremely appreciated!
Test that the unioned queries work individually.
If they don't, something in the design of the tables may have changed. In any case, check that the queries are returning data of the same type.
If they do, and you know that a) the whole union query has not changed at all and b) that it has worked in the past, then your intuition that the query is and has been fine is likely correct.
In my experience, I have found that this can also be due to corruption of the Access files. Sometimes, I would check for this first if I couldn't find any other logical explanation. In such cases, what has worked for me has been:
Attempt a Compact & Repair of the relevant file(s)
If the problem persists, then create a new Access file and import all objects from the old file to the new one, add any VBA references/libraries, compile it, Compact & Repair and then see if that fixes it.
Version 1 of the problem:
I create a simple (or complex) SQL query that works and save it, and then come back to it another day and try to run it. I get a message that it cannot find a field that is clearly in the table. If I copy the exact same query into a blank SQL window it works fine.
Version 2 of the problem:
Another version of this type of problem is when I write a query, run it a bunch of times, and then modify it in the same window, it sometimes (=quite often but not always) can't find a field that is clearly in the table. Again, copying the same query into a new window works just fine.
An example:
SELECT *
FROM table1
WHERE code1='xxx' and code2= 'yyy'
ORDER BY sortfield
I get the window saying 'Enter Parameter value for field Query1.sortfield' .
sortfield is in the table and copying this query to a new window works fine.
And to be clear, the query worked fine when first written.
Seems like Access is not properly clearing the buffer somehow.
I have Access 2010 and this happens very frequently, like maybe but not quite always, and seems to be getting worse. I have always had version 2 of the problem to some extent but version 1 is relatively new.
Does anyone have an idea of how to fix this?
Help is much appreciated!
I want write a query with active record and seems it never respect what I want to do. So, here are my example:
Phonogram.preload(:bpms).includes(:bpms).select("phonograms.id", "bpms.bpm")
This query returns all my fields from phonograms and bpms. The problem is that I need put more 15 relationships in this query.
I also tried use joins but didn't work properly. I've 10 phonograms and returns just 3.
Someone experienced that? How did you solve it properly?
Cheers.
select with includes does not produce consistent behavior. It appears that if the included association returns no results, select will work properly, if it returns results, the select statement will have no effect. In fact, it will be completely ignored, such that your select statement could reference invalid table names and no error would be produced. select with joins will produce consistent behavior.
That's why you better go with joins like:
Phonogram.joins(:bpms).select("phonograms.id", "bpms.bpm")
Browsing through the more dubious parts of the web, I happened to come across this particular SQL injection:
http://server/path/page.php?id=1+union+select+0,1,concat_ws(user(),0x3a,database(),0x3a,version()),3,4,5,6--
My knowledge of SQL - which I thought was half decent - seems very limiting as I read this.
Since I develop extensively for the web, I was curious to see what this code actually does and more importantly how it works.
It replaces an improperly written parametrized query like this:
$sql = '
SELECT *
FROM products
WHERE id = ' . $_GET['id'];
with this query:
SELECT *
FROM products
WHERE id = 1
UNION ALL
select 0,1,concat_ws(user(),0x3A,database(),0x3A,version()),3,4,5,6
, which gives you information about the database name, version and username connected.
The injection result relies on some assumptions about the underlying query syntax.
What is being assumed here is that there is a query somewhere in the code which will take the "id" parameter and substitute it directly into the query, without bothering to sanitize it.
It's assuming a naive query syntax of something like:
select * from records where id = {id param}
What this does is result in a substituted query (in your above example) of:
select * from records where id = 1 union select 0, 1 , concat_ws(user(),0x3a,database(),0x3a,version()), 3, 4, 5, 6 --
Now, what this does that is useful is that it manages to grab not only the record that the program was interested in, but also it UNIONs it with a bogus dataset that tells the attacker (these values appear separated by colons in the third column):
the username with which we are
connected to the database
the name of the database
the version of the db software
You could get the same information by simply running:
select concat_ws(user(),0x3a,database(),0x3a,version())
Directly at a sql prompt, and you'll get something like:
joe:production_db:mysql v. whatever
Additionally, since UNION does an implicit sort, and the first column in the bogus data set starts with a 0, chances are pretty good that your bogus result will be at the top of the list. This is important because the program is probably only using the first result, or there is an additional little bit of SQL in the basic expression I gave you above that limits the result set to one record.
The reason that there is the above noise (e.g. the select 0,1,...etc) is that in order for this to work, the statement you are calling the UNION with must have the same number of columns as the first result set. As a consequence, the above injection attack only works if the corresponding record table has 7 columns. Otherwise you'll get a syntax error and this attack won't really give you what you want. The double dashes (--) are just to make sure anything that might happen afterwords in the substitution is ignored, and I get the results I want. The 0x3a garbage is just saying "separate my values by colons".
Now, what makes this query useful as an attack vector is that it is easily re-written by hand if the table has more or less than 7 columns.
For example if the above query didn't work, and the table in question has 5 columns, after some experimentation I would hit upon the following query url to use as an injection vector:
http://server/path/page.php?id=1+union+select+0,1,concat_ws(user(),0x3a,database(),0x3a,version()),3,4--
The number of columns the attacker is guessing is probably based on an educated look at the page. For example if you're looking at a page listing all the Doodads in a store, and it looks like:
Name | Type | Manufacturer
Doodad Foo Shiny Shiny Co.
Doodad Bar Flat Simple Doodads, Inc.
It's a pretty good guess that the table you're looking at has 4 columns (remember there's most likely a primary key hiding somewhere if we're searching by an 'id' parameter).
Sorry for the wall of text, but hopefully that answers your question.
this code adds an additional union query to the select statement that is being executed on page.php. The injector has determined that the original query has 6 fields, thus the selection of the numeric values (column counts must match with a union). the concat_ws just makes one field with the values for the database user , the database, and the version, separated by colons.
It seems to retrieve the user used to connect to the database, the database adress and port, the version of it. And it will be put by the error message.
Trying to build a dashboard using Oracle's Brio. I have to access 6 different databases to grab the same type of data, aggregate it and display it. Except that when I do it, Brio grabs the data from the first source just fine. When I grab the data from the second data source, Brio replaces the original data with the second set. So I am not able to aggregate the data. Can anyone help me figure out how I can do this in Brio please?
You need to use a UNION statement, rather than running the query 6 times.
For example:
Don't do this
SELECT * FROM DATABASE_1..TABLE_1
GO
SELECT * FROM DATABASE_2..TABLE_1
GO
SELECT * FROM DATABASE_3..TABLE_1
GO
Do this instead
SELECT * FROM DATABASE_1..TABLE_1
UNION
SELECT * FROM DATABASE_2..TABLE_1
UNION
SELECT * FROM DATABASE_3..TABLE_1
GO
If you're using different OCE files for each source -- as you probably are -- then there's no easy way to do this. You'll need a separate query for each OCE file
If all your databases can be found under one OCE file, you can use the UNION trick; more to point, in Brio it's found as "Append Query". Just make sure you build the query identically to the first query in terms of what it returns; all the column headings will be from it.
If you need to consolidate the different queries into a single results section, the easiest -- well, only -- way that I've found to do it using only standard Brio functions is to join each set through a full outer join on every field and then coalesce each field together ... but this is horribly inefficient and will not finish for larger files. You'd probably be better off sorting the files and writing a javascript routine to parse them together, or doing the whole thing outside of Brio in the first place.