Using SSRS with VS 2017 I am receiving the ORA-01008 not all variables bound message when connecting to Oracle via the ole db connector. The code works normally through sql developer. Similar code worked fine in VS 2016 before we upgraded to vs 2017. Any ideas what's causing this issue
Code:
select tr.id_number
FROM rpt_transaction_view TR
WHERE TR.unit_code=:pUnit
Error Message:
TITLE: Microsoft SQL Server Report Designer
An error occurred while executing the query.
ORA-01008: not all variables bound
ORA-01008: not all variables bound
ADDITIONAL INFORMATION:
ORA-01008: not all variables bound
ORA-01008: not all variables bound (OraOLEDB)
BUTTONS:
OK
A little late BUT I think I found a solution (if you want to call it that). A little background, I've been working with SSRS since BIDS and have NEVER encountered this error before... until today. I have spent hours googling, trying to find what the solution is and NOTHING worked.
Now, I build all my queries in Oracle SQL Developer, and noticed something different about the offending query - the "SELECT" was underlined, basically Oracle SQL Developer wanted to rewrite the query, so I let it. Now I had two parameters, we'll call them :p1 and :p2, each being used three times throughout the query. When the query was re-written (to something almost unreadable) it replaced the parameters with :b1, :b2, :b3, :b4, :b5 and :b6. All odd parameters (:b1, :b3 and :b5) were :p1 and the evens :p2. I used a find and replace so I was back to only using the 2 parameters. I replaced the dataset in my report with this query, ran it and voila error gone...
Why? I have not the slightest idea. It's not like this query was unique to other queries I've used. I have over 400 oracle based reports and I've never had to do anything like this and this query wasn't as nearly as complicated as others I've written. I have some queries that use the same parameters a half dozen times and no issue - just this one.
Anyways, thought I would share in case anyone else was 100% stumped as I was.
Related
I have an SSRS Report it works perfectly when I use Oracle data source. However, when I tried to connect using OLEDB connection I am running into some issues.
0x80040e10 in the message file for OraOLEDB
I understand that its not receiving my parameter values.
For this report, I am using the date filters and applying to the report dataset in this manner
where trunc(addwhen) between (:sd) and (:ed)
Please can any help me figure out why I an running into this issue. It will be great help
Yeah as you know,its not receiving your parameter values.
This is because, Trunc is not a sql query, Try using CAST() or CONVERT() which serves the purpose
I've inherited a MS Access database which I should batch-update some data on. Thus, I've created a new query and as a first test tried to get some filtered record list - without success. Access strictly refuses to compile code that contains the LEFT function.
This does compile:
SELECT ColPath FROM MyTable;
This does not compile:
SELECT LEFT([ColPath], 3) FROM MyTable;
Even a simple
SELECT LEFT('Hello', 2);
doesn't work.
I've googled a lot now, and found solutions that either recommend checking the references in the Tools/References dialog in VBA view. There a no missing references in my case. A second solution was to check VBA modules for duplicate OPTION COMPARE DATABASE statements - none in my case.
I then created a brand new database and tried - surprisingly, everything works fine! I now compared the references of the new database to the old one: They are the same.
I'd be happy about any ideas on this...
Sounds like you messed up your references.
In the VBA editor, go to Tools, then References.
The top 2 should always be Visual Basic For Applications, then Microsoft Access ##.# Object Library, in that order (note the priority buttons to change order). Anything else will cause trouble.
Even though you have no missing references, incorrect ones can still cause this issue.
Second to that I'd do the general troubleshooting steps, decompile (Win R, MSACCESS.EXE /decompile, Open the database, hit Debug -> Compile) and a compact and repair. That will cause your entire database to recompile, and if your VBA code contains compile errors, that'll affect any queries calling any function.
I have a database which is split into an Oracle back end and Access front end applications. I tried to migrate the back end over to SQL Server, but when I did this using SSMA I lost functionality on a lot of the Access applications. I don't know where to start to resolve this, I'm thinking maybe there is a mismatch in the syntax? Is anyone able to lead me in the right direction into solving this?
Edit:
I identified the main error came from NULL values when trying to insert delegate names into a form for courses running.
SSMA has thrown up an 'Unparsed SQL' error on the below code:
CREATE OR REPLACE TRIGGER "ISTRAINING"."INSERT_COURSE_DELEGATES" BEFORE
INSERT ON "COURSE_DELEGATES" FOR EACH ROW declare
row_locked exception;
pragma exception_init (row_locked, -54);
begin
begin
select next
into :new.COURSE_DELE_ID
from ISTRAINING.sequence
where tname='COURSE_DELEGATES' and tcolname='COURSE_DELE_ID'
for update of next nowait;
exception
when row_locked then
raise_application_error (-20002,'Database temporarily locked');
end;
update ISTRAINING.sequence
set next=next+1
where tname='COURSE_DELEGATES' and tcolname='COURSE_DELE_ID';
end;
Does this help? I'm sorry I'm just a little lost and not sure what the right question is.
It not clear why issues would crop up. You make no mention of what does not work (you have to improve your question and add some examples of what does not work)
My car is broken does not help at all here.
Given that you had a working application, then all of the work and changes to make access work with Oracle should VERY much apply to SQL server.
In other words, the code changes required are close to identical in both cases.
The only area that would require changes if the application uses pass-through queries. This would mean that such code and quires are written in a 100% oracle SQL syntax as opposed to SQL server syntax.
For liked tables, and reports based on linked tables, then ZERO changes are required.
However, if ADO recordsets are being used, then that’s likely where changes are required.
So first up would be to identify if pass-through queries are used. I would simply check the syntax (simply run them) to see if they work. After the PT queries are addressed, then next up would be to search + scan and look at any ADO code (if ADO was used – we don’t even know this). If no ADO code exists, then few if any changes would and should be required here.
As noted, you not shared more information then that your car is broken – without details of what code or what in a form is failing, then we really have close to zero to go on here.
I work for a company where we likely going to update from Access97/2003 to Access2010.
After playing around with a prototype, I have found an issue when using Access 2010 with databases created in Access 2003.
Under some conditions, existing queries/SQL's in Access 2003 will become unusable in Access 2010. Here a small example:
Tablename: Parameters Field names: Number, Value
A query created with Access 2003 query designer:
SELECT Parameters.Value
FROM [Parameters]
WHERE (((Parameters.Number)=100));
this works fine with Access 2003.
In Access 2010 a error is raised: Syntax error in PARAMETER clause
A workaround for the error is to change the view in Access 2003. Here we get rid of the brackets:
SELECT Parameters.Value FROM [Parameters] WHERE Parameters.Number=100;
This will work in Access 2010 but the query remains unchangeable in the designer, because the query designer creates the syntax shown above.
The reason for this error is in fact the use of the reserved word 'Number', which shoudn't be used when you start to build a table or query, but for a migration with hundreds of existing databases, it is very likely or at least a risk to change the Access version without a complete test.
My idea is to write a small program which opens all the existing views and the tables to check if they work fine.
Anyway, dose anybody have a better solution for this, or is there a tool to check MS-Access 2003 databases to be compatible with Access 2010?
Many thanks in advance
Jörg
Parameters, Value, and Number are all reserved words. You may be right that Number is the culprit here; I would have suspected Parameters as more likely to confuse Access in a query.
"For a migration with hundreds of existing databases", first evaluate them with Allen Browne's Database Issue Checker Utility. In addition to the reserved words issue, it will give you an idea of other potential problem areas. Whether those issues will be more troublesome in Access 2010 than in 2003 is an open question.
However I don't see an easy solution for your predicament. You have hundreds of databases with perhaps thousands of tables and queries ... if they routinely incorporate reserved words for table and field names, as well as other object names ... your situation is miserable.
Experiment on a copy of an existing database. Turn on "track name autocorrect" and let it build the object dependencies. Change the table definitions to eliminate reserved words. Then see how much extra work you need to find and fix the items autocorrect didn't do for you. But don't leave autocorrect turned on in any application you release to your users.
I have been charged with maintaining a legacy classic ASP application. The application uses an ODBC system DSN to connect to a MySQL database.
We had to recently update the servers to satisfy some licencing requirements. We were on Windows, with MySQL 4.x and the 3.51 ODBC driver. We moved to a Linux machine running MySQL 5.1.43 and are running the 5.1.6 ODBC driver on the new IIS server.
Users almost instantly started reporting errors as such:
Row cannot be located for updating.
Some values may have been changed
since it was last read.
This is a ghost error, and the same data changes, on the same record, at a different time won't always produce the error. It is also intermittent between different records, as in, sometimes, no matter what values I plug in, I haven't been able to repro the defect on all records.
It is happening across 70 of about 120 scripts, many over 1,000 lines long.
The only consistency I can find is that on all of the scripts that fail, they are all reading/writing floats to the DB. Fields that have a null value don't seem to crash, but if there is a value like '19' in the database (note the no decimal places) that seems to fail, whereas, '19.00' does not. Most floats are defined as 11,2.
The scripts are using ADODB and recordsets. Updates are done with the following pattern:
select * from table where ID =
udpdated recordID
update properties of the record from the form
call RecordSet.Update and RecordSet.Close
The error is generated from the RecordSet.Update command.
I have created a workaround, where rather than select/copy/update I generate an SQL statement that I execute. This works flawlessly (obviously, an UPDATE statement with a where clause is more focused and doesn't consider fields not updated), so I have a pretty good feeling that it is a rounding issue with the floats that is causing a mis-match with the re-retrieval of the record on the update call.
I really would prefer NOT re-writing 100's of these instances (a grep across the source directly finds 280+ update calls).
Can anyone confirm that the issue here is related to floats/rounding?
And if so, is there a global fix I can apply?
Thanks in advance,
-jc
Have a look at MySQL Forums :: ODBC :: Row cannot be located for updating.
They seem to have found some workaround and some explanations as well..
I ran into a similar issue with a VBA macro utilizing 4.1. When upgraded to 5 errors started popping up.
For me the issue was that values being returned to VBA from MySQL was in a unhandled (by VBA) decimal format.
A CAST on the numbers when querying helped to fix the issue.
So for your issue perhaps the ODBC/ASP combination is recording/reading values differently then what you might expect them to be.