context
I have been working on a new wordpress blog as a personal website. Part of it, I have a custom contact form where people put in their details to get in touch with me.It has been working good till morning, after which I have updated to 4.2.2v citing security reasons.
problem
After the update, the form is failing to save any of the information into the DB. The $wpdb->insert_id is returning 0. The query is the same, the page is the same, everything is just the same. The only change is I have upgraded to 4.2.2v from 4.2.1v.
Is there any issue with the recent update or do I have to do any more steps after the word press manual update ?
debugging done...
I have ensured that the DB version is updated. It is showing 31535. When debugging using the $wpdb->lastquery and $wpdb->print_error() I get
WordPress database error: []
SHOW FULL COLUMNS FROM `wp_tst_tbl_contacts`
?
I could not understand what is wrong here. If I run the same insert query, as well as the above show full columns on command line using the same user wp user credentials, it works perfectly.
note: If there is anymore information needed, please ask.
I found the problem cause. Its due to a column width limitation.
I have a VARCHAR(9) column and I was sending data that is 16 char length. The new change in the 4.2.2 gets the table meta and crops the data such that it fits properly into the size of the column as defined in DB. And it also compares the pre-crop and post-crop data. If they don't match, it is failing.
The problem is, its failing silently with no error thrown. I have found this via debugging the wpincludes/wp-db.php file.
Please check your column limit and the column data length you send.
Once I have increased the column width (as the data will definitely be more than 9 chars), the issue got resolved.
I was experiencing this same issue and it turned out to be some unescaped values being pushed into the database from a csv import function.
I applied the proper esc_url() and / or esc_attr() and / or esc_html() where appropriate to sanitize the values pre-insertion and then the query ran successfully.
Related
I have spent two days researching and try to fix my issue with access form edits. I understand that there may be similar questions out there, but none of the suggestions fixed my problem. Also, my situation might be slightly different.
I'm on Access 2017 and using an access split form that is tied to a linked table that is on sql server 2017. I have an add button that simply adds the record entered and moves to a new record. When I add a record to my form and then try to edit it in the datasheet view on my split form I get a write conflict error.
I've already validated that I have a primary key on my table and that there are no null bit fields.
The other thing to note is that this started happening after migrating from SQL server 2014 to sql server 2017.
One thing I read about and have yet to try because of the "drastic" change it entails is to set the compatibility level of my database to something lower like SQL 2014. This would be a last resort however and would only be to validate what the cause of the error might be.
I've tried everything on this page that is applicable to my situation: http://www.accessrepairnrecovery.com/blog/fix-ms-access-write-conflict-error
What else can I try to resolve this? I'm hoping someone out there has run into something similar.
First this question has been answered 100's of time on stack overflow.
Next up: Your link has nothing to do with using SQL server, so the suggests likely will not help.
The main causes (repeated over and over as solution) when using Access and SQL server are:
Ensure that all tables have a PK defined.
Ensure that any bit fields have a default setup on sql server (usually 0)
Ensure that each table has a timestamp field.
This is important, espeically if you have any floating or "real" data type columns. The Access up-sizing wizard, and the migration tool for Access both by default suggest and will add the timestamp field.
If you missing any of the above 3 issues (that have been repeated over and over for the last 18 years on near every article about using SQL server.
So, you will ensure that you checked above all 3 issues.
After any table changes, you will re-link the access client side.
You then need to test/check if you can change edit data using the linked table directly from access (in table view). if you can edit such data directly, then you are back to testing with your form. If the form still causes a write conflict, then suggests in the article you linked to will START to apply, but not until such time you address and ensure all 3 above steps are issues are dealt with.
The time stamp is often required for a sub form, and also when you have real/floating columns. Due to rounding errors in such computer numbers, then the compare between the two records fail. The adding of the timestamp column fixes this issue since access now does not have to do a field by field compare, but will use the timestamp column (not to be confused with a datetime column) to figure out if record has been changed. Thus adopting this feature even reduces the network chatter from client to server and allows access to determine if server record been changed without having to resort to a field by field compare.
I recently encountered the same error and it turned out to be that I had an active sort on the datasheet view. Once I removed the sort, voila, problem solved! (Nothing like shooting myself in the foot.)
The error message "The search key was not found in any record" was appearing on one record of a table in Access 2010.
I first noticed this when accessing that record via an update query, but later found that I also got the same error when trying to delete the record.
What causes this, and how can it be resolved?
It was just a database corruption, but I was misled by it only affecting one record. A Compact and Repair sorted it immediately.
Sometimes this happens because the field name contains a leading space, ensure your field names are trimmed before and after.
Example: It happened to me when I was trying to import an Excel sheet contains the first row as field names, two of the field names was " Latitude" and " Longitude". From this post I knew the problem's cause, so I changed them to "Latitude" and "Longitude" (without the leading space), and the problem was solved.
I know this is an old post, but i just ran into this issue and none of the other answers seemed to solve or address my scenario.
Using a copy of the dbase, i had to continue to delete tables until the error message ceased.
The table at fault was a hidden, system table with the name MSysComplexColumns. I deleted it, closed the dbase and the table was auto-created upon re-opening the dbase. That completed solved it with no side effects.
In my case, this error message was triggered by the size of my Access file. When its size exceeded 2,000,000 KB, the message popped up when I was importing another document. As long as I reduced its size, the message stopped and the import process finished successfully.
Also check the database version. I was having the problem with VBA CreateDatabase(sTempDBName, dbLangGeneral) in Access 2010 where I was using a 2003 database trying to link a table in a 2010 database. When I manually tried the link I got a message about no support for linking to a later version. Creating the temp database I was trying to link to using the option dbVersion40 "CreateDatabase(sTempDBName, dbLangGeneral, dbVersion40)" cured it.
It is very strange what is happening, I have never seen this before and I am pretty familiar with mysql.
When searching a table using the phpMyAdmin table search feature, the result is empty no matter what I put. For example, searching 77 in the ID column returns empty result. However if I run an SQL query also in phpMyAdmin, and then there is the result. For example, select * from table1 where id = ‘77’;
What is even more strange is this only happens on one table, all other tables the search feature is working fine.
I tried repairing the table but empty result still occurs.
I couldn’t find this happening anywhere to any one online…..
Also restarted sql server.
Are you using cPanel - if yes I just described how to fix the problem on cPanel forums:
http://forums.cpanel.net/f5/unable-use-phpmyadmin-search-users-table-313381.html
If your table has a large number of fields an update via the phpMyAdmin interface can exceed the value for the PHP setting 'max_input_vars'. When this happens some of the internal form fields that phpMyAdmin is expecting to receive on the page your update is being posted to are truncated which causes phpMyAdmin to fail, unfortunately silently, and the page redirects with no warnings back to the blank search form. The default for 'max_input_vars' is 1000. I upped mine in my php.ini file to 5000 with no negative side affects and it solved this problem for me.
The setting 'max_input_vars' has a mode of PHP_INI_PERDIR so if you don't have access to your php.ini file then you may be able to set it in an .htaccess file, your httpd.conf file or your .user.ini (since PHP 5.3) file if you have one. I'm not sure exactly what code you would need for an htaccess file but the PHP code to do it is below.
ini_set('max_input_vars', '5000');
Hopefully that should get you started in the right direction.
Very easy. Go to the table and expose max number of rows as much as is showed in the dropdown. Then you are able to search per big pages. It doesnt fetch text through all the table. It plays only with a page of the table.
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.
Just moved a site over to a new server and we started getting some errors. Mainly that some data we were passing into a MySQL table was too long for the field. Having checked through the DB it seems the old server was truncating the data to fit the table, yet the new server throws a TEP STOP. Any ideas what the setting is to switch this back on, to temporarily get stuff working again?
Thanks!
MySQL used to be famous/infamous for silently "correcting" data it could not store directly (overlong strings, invalid dates) etc.. That has fortunately changed in recent versions.
You can now configure this behaviour using "Server SQL Modes". You probably want to switch off STRICT_ALL_TABLES or STRICT_TRANS_TABLES.
See MySQL's docs for details.