I am using Access(2003) mdb file as front end of oracle 11g R2 as backend. I am using odbc connection to retrieve data from oracle database. But sometime mdb is displaying incorrect output.
For example, when I use the below query in mdb
SELECT *
FROM PLAN
WHERE (((PLAN.BATCH_REF)="SSU080520122"));
and it is providing wrong result. But the same query is providing correct result in oracle.
Any help will be appreciated.
PLAN is a reserved word. Using reserved words as table or column names can confuse the db engine. Although this may not actually be the source of your trouble, it would be easy to rule it out as a contributor. See if you get the results you expect with this query:
SELECT *
FROM [PLAN] AS p
WHERE p.BATCH_REF="SSU080520122";
Related
I am currently working on a query in Access 2010 and I am trying to get the below query to work. I have the connection string between my local DB and the server that I am passing through to working just fine.
Select column1
, column2
from serverDB.dbo.table1
where column1 in (Select column1 from tbl_Name1)
In this situation table1 is the table on the server that I am passing through to get to, but the tbl_Name1 is the table that is actually in my Access DB that I am trying to use to create constraints on the data that I am pulling from the server.
When I try to run the query, I am getting the error that it doesn't think tbl_Name1 exists.
Any help is appreciated!
I just came across a solution that may help others in a similar situation.
This approach is easy because you can just run one query on your local Access database and get everything you need all at once. However, a lot of filtering/churning-through-results may be done on your own local computer behind the scenes, as opposed to on the remote server, so it may not necessarily be quick.
Steps
Create a query, make it a "Pass Through" query, and set up its "ODBC Connect Str" property to connect to the remote database.
Write the pass through query, something like SELECT RemoteId From RemoteTable and give your pass through query a name, maybe PassThroughQuery
Create a new query, make it a regular "Select" query.
Write your new query, using the pass through query you just created as a table in this new query (seems weird to use a query as a table, but it works) and join that PassThroughQuery "table" to your local table and filter it based on values in the local table, something like SELECT R.RemoteId, L.LocalValue FROM PassThroughQuery R INNER JOIN LocalTable L ON L.LocalId = R.RemoteId where L.LocalValue = 'SomeText'
This approach allows you to mix/join the results of a pass through query and the data in a local Access database table cleanly, albeit potentially slowly if there is a lot of data involved.
I think the issue is that a pass through query is one that is run on the server. Since one of the tables is located on the local Access file, it won't find the table.
Possible workaround if you must stay with the pass-through is you can build an SQL string with the results of the nested query rather than the query string itself (depending on the number of results this may or may not be practical)
e.g. Instead of Select column1 from tbl_Name1 you use "c1result1","c1result2",....
I need to create a data dictionary that lists all the tables, columns and data types in PDF file format. I use SQL Server 2008 R2. How do I get this information?
I was able to view the schema view as someone suggested with all the information I need, but how to make a PDF file format with that information?
I would recommend using a paid product for what you're looking for, http://www.sqldatadictionary.com/ , http://www.apexsql.com/sql_tools_doc.aspx , or http://www.red-gate.com/products/sql-development/sql-doc/ ..
You can use dataedo if you looking for tool with gui. Has free version. Program semi-automatically generates the database schema and then can export schema to pdf or html format. It worked for me.
Best file result when used MS Access data documenter do it for you. I first used a tool to convert MS SQL db to MS Access db. Then I used data documenter tool within MS Access.
Thank you all for helping me.
look at the
SELECT *
FROM SYS.OBJECTS A
LEFT JOIN SYS.COLUMNS B ON A.OBJECT_ID = B.OBJECT_ID
WHERE A.TYPE_DESC = 'USER_TABLE'
and select your specific columns
I was helping a non-profit migrate MS-Access data to MYSQL. So, I ported data to MYSQL and created links in ms-access to MYSQL tables using ODBC. Majority of the existing SQL works fine. However I am stumped on this one error -
You have an error in your SQL syntax check the manual that corresponds to your MySQL server version for the right syntax to use near UNION...
I have stripped the SQL with 7 UNIONS to bare bones where it still fails.
(SELECT 1 as A FROM Households H)
UNION ALL
(SELECT 2 as A FROM Households H)
UNION ALL
(SELECT 3 as A FROM Households H)
The part that is getting to me is that I am able to run above successfully as long as I run only one UNION meaning below SQL, but the moment I add a third one, it gives ODBC error
(SELECT 1 as A FROM Households H)
UNION ALL
(SELECT 2 as A FROM Households H)
I tried using ` or ' or [] but none of these helped. The reason I am frustrated with this error is that either it should fail with all or none, it gives an error only when using two or more UNION clauses. Could this be a potential bug in driver?
I am using mysql-64 bit on win-7 64bit with ms-access and a 32-bit driver. It shouldn't be an architecture problem as I am able to run other queries with multiple UNIONs, and accessing the same set of tables.
It would be great if someone can give pointers on how to debug this further.
In my version of Access, when I edit a query in Design (SQL) view there are three buttons at the top. "Union", "Pass-Through", and "Data Definition".
If I click "Pass-Through" your query works. If I click "Union" it breaks. Can you get away with using "Pass-Through" for this query?
Even in "Union" or "Data Definition" mode, this seems to work:
(SELECT 1, column1 as A FROM Households H)
UNION ALL
(SELECT 2, column2 as A FROM Households H)
UNION ALL
(SELECT 3, column3 as A FROM Households H);
Maybe Access is confused by only a single column?
Alternatively, just use a a multiplex table instead of a union:
SELECT mux.id,
IIf(mux.id=1,column1,IIf(mux.id=2,column2,column3)) AS A
FROM Households, mux;
Note: mux table should have 3 values in it 1,2,3. If it has more, you'd want to limit to the first 3 (or n) in a where clause.
It is a known MySQL problem: more than two UNION SELECT statement problem (with MS Access) but I don't know if the problem is in the MSAccess SQL parser (which compiles to ODBC SQL), or in the MySQL ODBC driver (which compiles ODBC SQL to MySQL SQL)
To work it out, I'd have to look at the ODBC log, and the ODBC specification, and see if Access was emmitting valid ODBC SQL.
That would be a waste of effort, since it makes more sense to use a pass-through query anyway. The main reason for using a native MSAccess query in this place would be to join to different data sources - for example, an Excel Spreadsheet and a MySQL table -, and according to the comments on the MySQL bug report, the problem goes away when you do that.
I am not sure about where the problem lies, but I think (though it's only an assumption) that this is on MS Access side. I had two UNION queries, each of them was putting some other queries together. Both used somewhat complicated sub-queries so I had lots of problem to create a pass-through query and I didn't want to use MySQL "views".
Surprisingly one of my queries worked, the other showed an error. My idea is that the working query used some Access features while the other was some kind of SELECT ... FROM's .
I don't know the rules but I think that when your query is simple, Access sends it to external database engine and puts one more bracket and causes an error. If you do a comlicated query, Access gets all data it needs and makes all necessary operations itself. For example, you may try to create a pivot query, that uses MSSQL TRANSFORM statement, which does not exist in MySQL, so it is obvious that Access handles it itself. So why couldn't it make SELECT by itself? I don't know. Maybe some performance reasons?
My working query differed from the other that it had one more (string) field that was calculated by built-in Access function. It used also Access & operator, which has another meaning (logical AND) in MySQL. (By the way to join strings in MySQL use CONCAT function). They of course need to be evaluated by Access, because MySQL does not understand this method of joining strings together.
I suggest just to make UNION not from tables, but from queries (like SELECT * FROM tablename and nothing more) and giving them a field that you don't need but that will force Access to handle the query. So a query (in Access) should look like this:
SELECT tablename.*, [somefield1]&[somefield2] AS useless_field FROM tablename;
(in my Access 2000 operations like "a" & "b" or IIf(true;true;false) were probably simplified and solved, so it didn't work. I think one needs at least one dynamic field to evaluate. I also did no performance tests. Probably it would be fastest if you add to integers, maybe just increase your index by 1?).
Then, of course, you join it together:
SELECT * FROM query1
UNION ALL
SELECT * FROM query2
UNION ALL
SELECT * FROM query3
UNION ALL
...
SELECT * FROM queryn
;
You don't need this useless_field of course.
I agree that this is a workaround but I have no other ideas.
I am trying to set up a third party MySQL as a Linked Server on SQL Server 2008.
When I try to access the data via a simple OpenQuery below I get an error.
SELECT * FROM OpenQuery(SERVERNAME, 'SELECT * FROM table')
The error message:
OLE DB provider 'MSDASQL' for linked server 'SERVERNAME' returned data that does not match expected data length for column '[MSDASQL].tablename'. The (maximum) expected data length is X, while the returned data length is Y.
NOTE:(where X > Y)
I've tried with another MySQL table that I built myself and it works fine. Therefore I assume the problem might be with the MySQL source.
EDIT: After digging a little deeper into the MySQL data I found several "invalid" dates such as zero dates. These could be a reason, however I have no way to change the data source so I must find a way to convince SQL to ignore it.
I recall something form previous versions of SQL where you could switch to "Lazy Schema Validation" to force SQL not to check this. However this option appears to be gone in 2008.
Any ideas how I could make this work?
So I was playing with my MS SQL Server 2008 app to see how good it is protected against SQL injections. The app lets users to create views in the database.
Now consider the following:
create view dbo.[]]; drop database foo--] as select 1 as [hi!]
This creates a view with a name of ]; drop database foo--. It is valid and you can select from it (returns the number 1, obviously).
Strange thing #1:
In SQL Management Studio, the query SELECT [hi!] FROM [dbo].[]]; drop database foo--] is red-underlined as incorrect, claiming that the object name is not valid. Nevertheless, it executes and returns the 1.
Strange thing #2:
Call to OBJECT_ID(']; drop database foo--') yields NULL (which means the object does not exist), but the following query returns information about the view properly:
select * from sys.objects where name = ']; drop database foo--';
Are those bugs or am I missing a point?
You're missing the point. SQL Server can't protect itself against SQL injection - if somebody has direct access to your database then you've already been pwned. It's your application that needs to protect against SQL injection by parameterizing queries, and preventing these kinds of statements from ever making it to the database.
1: that only means the intellisense parser is not up to par witht the finer details of SQL syntax. While it may be an intellisense bug, it is not an injection vector.
2: object_id() accepts multipart names, so it needs the name in quotes if ambiguous: select object_id('[]]; drop database foo--]')
That's like using your key to get into your car and then saying "hey there's a security hole, I'm allowed to steal the radio"
It seems the problem is that you are yourself causing SQL injection by accepting user input and using it as SQL statement text.
The fact that you "properly escaped" the ] (by substituting with ]]) really doesn't matter - it's you allowing the user input to be used as anything else but a value by definition means you allow SQL injection.