Description: i have a problem executing the prepared statement more than once with binding parameters. 1st time it executing correct then resetting the parameters,statement and when i try to execute same prepared statement next time it is failed giving the error like this.
Details: i am executing a prepared statement with binding some parameters ,after executing i am resting the prepared statement and unbinding the parameters. when try to execute the same prepared statement it is giving the error :"27:Error fetching numeric attribute: ColAttribute for this type not implemented yet". i am using libodbc++ library. when i debug it is going wrong at this line(libodbc++ code line)
Line :ResultSet* rs=ODBCXX_OPERATOR_NEW_DEBUG(FILE, LINE) ResultSet(this,hstmt_,hideMe);
Error: "27:Error fetching numeric attribute: ColAttribute for this type not implemented yet"
PostgreSQL version number you are running:
How you installed PostgreSQL:PostgreSQL 9.3.5, compiled by Visual C++ build 1600, 64-bit
Changes made to the settings in the postgresql.conf file: No
Operating system and version:windows 8.1 (64-bit)
What program you're using to connect to PostgreSQL:ODBC 3.5 (libodbc++) library
Is there anything relevant or unusual in the PostgreSQL server logs?:No
For questions about any kind of error:
What you were doing when the error happened / how to cause the error:"27:Error fetching numeric attribute: ColAttribute for this type not implemented yet"
Thanks & Regards
Balakrishna
The issue is with how the libodbc++ handles the parameters and the queries. There are two ways to fix this :
1. Upgrade the libodbc++ to use 7.4(V3) protocol.
2. If you are using old libodbc++, then change disable the UseServerSidePrepare parameter in odbc configuration files.
Explaination for UseServerSidePrepare = 0 in odbc configuration :
The psqlodbc controls more than just whether to use unnamed or named
plans in the server. With UseServerSidePrepare=0, parameters are
handled completely in the driver, replacing the parameter markers with
the values in the query itself.
Note : There may well be applications where UseServerSidePrepare=1
gives a performance hit, especially when running against < 9.2 servers.
It's still a better default IMHO, you can still turn it off if you have to.
PS: I know the question was asked years back, but i recently faced the same issue and had to very less resource which actually worked.
Related
In my local/development environment, the MySQLi query is performing OK. However, when I upload it on my web host environment, I get this error:
Fatal error: Call to a member function bind_param() on a non-object in...
Here is the code:
global $mysqli;
$stmt = $mysqli->prepare("SELECT id, description FROM tbl_page_answer_category WHERE cur_own_id = ?");
$stmt->bind_param('i', $cur_id);
$stmt->execute();
$stmt->bind_result($uid, $desc);
To check my query, I tried to execute the query via control panel phpMyAdmin and the result is OK.
TL;DR
Always have mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); in your mysqli connection code and always check the PHP errors.
Always replace every PHP variable in the SQL query with a question mark, and execute the query using prepared statement. It will help to avoid syntax errors of all sorts.
Explanation
Sometimes your MySQLi code produces an error like mysqli_fetch_assoc() expects parameter 1 to be mysqli_result, boolean given..., Call to a member function bind_param()... or similar. Or even without any error, but the query doesn't work all the same. It means that your query failed to execute.
Every time a query fails, MySQL has an error message that explains the reason. In the older PHP versions such errors weren't transferred to PHP, and all you'd get is a cryptic error message mentioned above. Hence it is very important to configure PHP and MySQLi to report MySQL errors to you. And once you get the error message, fixing it will be a piece of cake.
How to get the error message in MySQLi
First of all, always have this line before MySQLi connect in all your environments:
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
After that, all MySQL errors will be transferred into PHP exceptions. An uncaught exception, in turn, makes a PHP fatal error. Thus, in case of a MySQL error, you'll get a conventional PHP error. That will instantly make you aware of the error cause. And the stack trace will lead you to the exact spot where the error occurred.
How to get the error message from PHP
Here is a gist of my article on PHP error reporting:
Reporting errors on a development and live servers must be different. On the development server it is convenient to have errors shown on-screen, but on a live server error messages must be logged instead, so you could find them in the error log later.
Therefore, you must set corresponding configuration options to the following values:
On a development server
error_reporting should be set to E_ALL value;
log_errors should be set to 1 (it is convenient to have logs on a development PC too)
display_errors should be set to 1
On a production server
error_reporting should be set to E_ALL value;
log_errors should be set to 1
display_errors should be set to 0
After that, when MySQL query fails, you will get a PHP error that explains the reason. On a live server, in order to get the error message, you'll have to check the error log.
In case of AJAX call, on a dev server open DevTools (F12), then Network tab. Then initiate the request which result you want to see, and it will appear in the Network tab. Click on it and then the Response tab. There you will see the exact output. On a live server check the error log.
How to actually use it
Just remove any code that checks for the error manually, all those or die(), if ($result), try..catch and such. Simply write your database interaction code right away:
$stmt = $this->con->prepare("INSERT INTO table(name, quantity) VALUES (?,?)");
$stmt->bind_param("si", $name, $quantity);
$stmt->execute();
Again, without any conditions around. If an error occurs, it will be treated like any other error in your code. For example, on a development PC it will just appear on-screen, while on a live site it will be logged for the programmer, whereas for the user's convenience you could use an error handler (but that's a different story which is off topic for MySQLi, but you may read about it in the article linked above).
What to do with the error message you get
First of all you have to locate the problem query. The error message contains the file name and the line number of the exact spot where the error occurred. For the simple code that's enough, but if your code is using functions or classes you may need to follow the stack trace to locate the problem query.
After getting the error message, you have to read and comprehend it. It sounds too obvious if not condescending, but learners often overlook the fact that the error message is not just an alarm signal, but it actually contains a detailed explanation of the problem. And all you need is to read the error message and fix the issue.
Say, if it says that a particular table doesn't exist, you have to check spelling, typos, and letter case. Also you have to make sure that your PHP script connects to a correct database
Or, if it says there is an error in the SQL syntax, then you have to examine your SQL. And the problem spot is right before the query part cited in the error message.
If you don't understand the error message, try to google it. And when browsing the results, stick to answers that explain the error rather than bluntly give the solution. A solution may not work in your particular case, but the explanation will help you to understand the problem and make you able to fix the issue by yourself.
You have to also trust the error message. If it says that number of tokens doesn't match the number of bound variables then it is so. The same goes for the absent tables or columns. Given the choice, whether it's your own mistake or the error message is wrong, always stick to the former. Again it sounds condescending, but hundreds of questions on this very site prove this advise extremely useful.
A list of things you should never ever do in regard of error reporting
Never use an error suppression operator (#)! It makes a programmer unable read the error message and therefore unable to fix the error
Do not use die() or echo or any other function to print the error message on the screen unconditionally. PHP can report errors by itself and do it the right way depends on the environment - so just leave it for PHP.
Do not add a condition to test the query result manually (like if($result)). With error exceptions enabled such condition will just be useless.
Do not use the try..catch operator for echoing the error message. This operator should be used to perform some error handling, like a transaction rollback. But never use it just to report errors - as we learned above, PHP can already do it, the right way.
P.S.
Sometimes there is no error, but no results either. Then it means, there is no data in the database to match your criteria. In this case you have to admit this fact, even if you can swear the data and the criteria are all right. They are not. You have to check them again.
I've got an article that can help in this matter, How to debug database interactions. Although it is written for PDO, the principle is the same. Just follow those instructions step by step and either have your problem solved or have an answerable question for Stack Overflow.
I've looked at all of the similar questions on stack overflow. This one is different enough to warrant a separate question. Basically, I can't start a repl server because I get the error below. It's been pointed out that this is typically a dependency issue, but I'm updated, to my knowledge. What am I getting wrong here? Here's the full error:
error in process sentinel: Could not start nREPL server: java.lang.NumberFormatException: Invalid number: 0.8.3
at clojure.lang.LispReader.readNumber (LispReader.java:352)
clojure.lang.LispReader.read (LispReader.java:278)
clojure.lang.LispReader.readDelimitedList (LispReader.java:1398)
clojure.lang.LispReader$VectorReader.invoke (LispReader.java:1347)
clojure.lang.LispReader.read (LispReader.java:285)
clojure.lang.LispReader.read (LispReader.java:216)
clojure.lang.LispReader.read (LispReader.java:205)
clojure.lang.RT.readString (RT.java:1878)
clojure.lang.RT.readString (RT.java:1873)
clojure.core$read_string.invokeStatic (core.clj:3815)
clojure.core$read_string.invoke (core.clj:3805)
clojure.core$mapv$fn__8445.invoke (core.clj:6912)
clojure.core.protocols$fn__8159.invokeStatic (protocols.clj:168)
clojure.core.protocols/fn (protocols.clj:124)
clojure.core.protocols$fn__8114$G__8109__8123.invoke (protocols.clj:19)
clojure.core.protocols$seq_reduce.invokeStatic (protocols.clj:31)
clojure.core.protocols$fn__8146.invokeStatic (protocols.clj:75)
clojure.core.protocols/fn (protocols.clj:75)
clojure.core.protocols$fn__8088$G__8083__8101.invoke (protocols.clj:13)
clojure.core$reduce.invokeStatic (core.clj:6828)
clojure.core$mapv.invokeStatic (core.clj:6903)
clojure.core$mapv.invoke (core.clj:6903)
leiningen.update_in$parse_args.invokeStatic (update_in.clj:13)
leiningen.update_in$parse_args.invoke (update_in.clj:9)
leiningen.update_in$update_in.invokeStatic (update_in.clj:36)
leiningen.update_in$update_in.doInvoke (update_in.clj:24)
clojure.lang.RestFn.applyTo (RestFn.java:146)
clojure.lang.Var.applyTo (Var.java:705)
clojure.core$apply.invokeStatic (core.clj:667)
clojure.core$apply.invoke (core.clj:660)
leiningen.core.main$partial_task$fn__7331.doInvoke (main.clj:284)
clojure.lang.RestFn.applyTo (RestFn.java:139)
clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invokeStatic (core.clj:667)
clojure.core$apply.invoke (core.clj:660)
leiningen.core.main$apply_task.invokeStatic (main.clj:334)
leiningen.core.main$apply_task.invoke (main.clj:320)
leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:343)
leiningen.core.main$resolve_and_apply.invoke (main.clj:336)
leiningen.core.main$_main$fn__7420.invoke (main.clj:453)
leiningen.core.main$_main.invokeStatic (main.clj:442)
leiningen.core.main$_main.doInvoke (main.clj:439)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.core$apply.invokeStatic (core.clj:665)
clojure.main$main_opt.invokeStatic (main.clj:514)
clojure.main$main_opt.invoke (main.clj:510)
clojure.main$main.invokeStatic (main.clj:664)
clojure.main$main.doInvoke (main.clj:616)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.main.main (main.java:40)
EDIT:
So I've gotten farther on this problem and I think I'm down to the last little issue or two. The file that is being pulled that causes the java.lang.NumberFormatException is cider.el which you can finder in your emacs.emacs.d\elpa\cider-[VERSION NUMBER, in my case 20210104.915]. You open your cider.el file and on line 392/393, in this version, you'll find:
(cider-add-to-alist 'cider-jack-in-dependencies
"nrepl/nrepl" "0.8.3")
So changing this line, recompiling it, and reloading emacs gets the number throwing the java.lang.NumberFormatException to change to whatever I changed it to (recompile by using byte-compile-file, hitting enter, then passing it the address of the document). Adding another set of double quotes gets a null value error of sorts (obviously) and doing any type of backslashing for exceptions and sort doesn't seem to solve the issue. So, since the few related posts (though with much less detail) seem to hint at changing the version number, I'm going to have to assume that I have to do that. What version number would work best here?
TEMP SOLUTION SO FAR:
start a repl with "lein repl" in command line and connect to it manually using the connect command "cider-connect" and specifying the localhost (I started the repl in same directory as project and it detected it easily). This is not good enough for me as a permanent solution but gets me up and going temporarily until a better solution is found.
PERMANENT SOLUTION:
see below
Look at your dependencies. I had an issue where my java jdk was basically broken (java's fault, not mine, in so far as the code is concerned). I ended up using the latest OpenJDK (number 15). That worked. If you get lots of java specific type errors and those errors change with the versions that you're using, then consider updating your java jdk. I was using LTE versions before and the latest fixed it.
Site works fine. Suddenly it will through an error. When clicking "flush system cahce" the error will go away for a some time. Anything from minuttes to severaæ hours.
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1247602160:
Unknown column 'tx_my_domain_model_formular.rel_formular' in 'where
clause' |
TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException
thrown in file
/webserver/typo3/src/6.2.15/typo3/sysext/extbase/Classes/Persistence/Generic/Storage/Typo3DbBackend.php
in line 862.
It is correct that the columns does not exist. But how to preceed in finding the error after this? Where is the sql generated that causes the site to crash?
UPDATE
A check "myParentObj->getChildObj instanceof myChildObjClass" used to work just fine. After changing myParent model to lazy load the ChildObj, then the class of childObj changed from childObjClass to a lazyLoadClass... I am not sure but I guess that is in turns somewhere somehow caused the core error seen in the log.
How to investigate further I simply cannot work out. Eg. store all DB calls in a file og DB to analyze after the error occours.
First
Please take time to write a good question. For a good question you'll get a good answer. It doesn't have to be perfect (not everyone is a native english speaker) but please reread your question.
Answer
If all fields are defined correctly, just run a DB compare from within the installtool.
If not, you need to define the DB-fields in your extension correctly.
Is this your own extension? When doing the query that triggers the error you could call execute(true) to generate the actual SQL statement and debug from there.
When I run pg_dump on my database, it's converting one of my views (orders_plus) to a table, and then creating a rule that I guess puts it back to the equivalent of a view. That seems to be OK (though strange). However, right after the 'CREATE RULE' it puts this line:
ALTER VIEW orders_plus SET ();
That's not a valid command, and so I get an error when recovering the database.
pg_dump should never do this. This is a problem with your server or your client. Since you got this from Apple and it may be customized follow up with them.
My guess is that one of the pg_get_* functions is failing. This could be an issue with data in your system tables or it could be issues with the server-side functions. But I have never seen anything like this before anywhere else so Apple would be the place to start.
... 3 years later ...
Seems you stumbled upon a bug in v9.2.1, which was fixed in v9.2.2.
See v9.2.2 release notes:
Fix pg_dump for views with circular dependencies and no relation
options (Tom Lane)
The previous fix to dump relation options when a view is involved in a
circular dependency didn't work right for the case that the view has
no options; it emitted ALTER VIEW foo SET () which is invalid syntax.
I recently noticed the exact same issue when restoring/migrating a production database. I used an older version of pg_dump than the database by mistake;)
psql:dump.sql:27821784: ERROR: syntax error at or near ")"
LINE 1: ALTER VIEW <viewname> SET ();
The problem went away when using pg_dump v9.2.6.
For completeness, here's some software info: Postgres version 9.2.6 GNU/Linux 2.6.18-406.el5 #1 SMP Fri May 1 10:37:57 EDT 2015 x86_64. Red Hat Enterprise release 5.11 (Tikanga).
Using a perl script (Perl 5.8.6), I'm connecting to Sybase dataserver.
Looking for the following:
How many connections are currently opened by the script.
Generic (non-dataserver specific) Error handling modules/mechanism
When executing a stored proc, it returned the following error message.
DBD::Sybase::st execute failed: Server
message number=27000 severity=16
state=1 line=4 server=SYBDEV_HYD
procedure=j_err text=But this one does
[for Statement "EXEC sandbox..j_err"]
at
/usr/local/lib/perl5/site_perl/5.8.6/DBIx/ContextualFetch.pm
line 51.
Since the user of this script is a non-techie, trying to report only the message "But this one does" (that appears after the text=). Though I can parse this, trying to see if there is any generic module, since other dataserver (like MySQL, SQL Server etc.) can have their own way of reporting the error msg.
I'm not quite sure what you're asking, but you'll find a lot of information by reading through the documentation for DBD::Sybase and DBI. You probably have to keep track of the number of connections yourself (see the example for DBI->connect).
For error-handling, you should probably just compose a reasonable diagnostic message yourself along with a line number - you can do this easily with warn() or carp().
Please also feel free to edit your question with more specifics about what you are trying to do; some sample code would be helpful.