I need help with MySQL database. I migrated a website to a new hosting provider and now im getting this error.
Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in /home/content/21/11026521/html/index.php on line 106 (on the test site)
I;m not a technical person but im trying to fix this issue. Can someone help.
I'm not sure what else information to provide you with.
Most important info you didn't provide is how you "migrated" your website, especially the database.
Did you keep all your table schematics? This is really important. Just make sure all your rows in all your tables are in the same order, have the same name, accept the same datatype and maybe even have the same constraints as before.
If you could post some snippet of your php and the corresponding mysql table layout, we can go into depth with error analysis here.
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.)
I am using the migration wizard provided by MySQL workbench 6.3 to convert a SQL Server database into a MySQL. I tested the connection between both DBs and they are valid for the migration wizard. Once The migration wizard has completed I am left with 22 migration warnings and they are all the same warning:
Truncated key column length for column 0 to 16
I am having a hard time finding any similarities between the tables that are receiving warnings to narrow down the issue. There are tables with the same types of data that are not receiving these errors.
Here is an example of one of the tables affected by this warning.
Does anyone know what is/what could be causing these migration warnings?
if you need more information/images please let me know.
Migration wizard show this warning when find index that have different length on source and target databases. In fact you should also get index name in that message - ... for column <name> from ..., but it's empty. I guess something goes wrong, but to investigate that I need to reproduce issue on my machine. Please fill bug report on bugs.mysql.com and attach there sample database (you can make it private if you wish). Then paste link here.
Warning doesn't matter. Just remember to rename the schema while migrating I have attached an image for better understanding
https://i.stack.imgur.com/v6PGK.png
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.
This is very specific question and need suggestion specific to my website or server only.
Website: www[dot]admission[dot]aglasem[dot]com
My error log size increases up to 4 GB in a day, it does not go beyond that, may be due to some restrictions.
I check the error log file and found a single error type logged repetitively
Here is the error-log part
WordPress database error Table 'asadm_main.wp_postmeta' doesn't exist for query
SELECT COUNT(meta_id)
FROM wp_postmeta
WHERE meta_key='_menu_item_menu_item_parent'
AND meta_value='64'
made by require('wp-blog-header.php'),
require_once('wp-includes/template-loader.php'),
include('/themes/magazine/magazine.php'), get_header, locate_template,
load_template, require_once('/themes/magazine/header.php'),
wp_nav_menu, walk_nav_menu_tree, call_user_func_array, Walker->walk,
Walker->display_element, call_user_func_array,
Walker_Nav_Menu->start_el, apply_filters('nav_menu_css_class'),
call_user_func_array, astro_add_dropdown_class
I think this is theme specific issue. Can someone please explain what is going on and suggest me possible solutions for the same.
There is a lot we don't know based on your post.
My guess is that you are using a plugin/theme that has hard coded "wp_" as the table prefix instead of getting it from the $wpdb variable...and that your table prefixes are NOT "wp_".
If you NEED to use the offending plugin/theme...you might be able to get away by creating a view.
CREATE VIEW wp_postmeta AS SELECT * FROM <put your actual postmeta table name here>
This error ('wp_postmeta' doesn't exist) is evidence of a serious misconfiguration of WordPress. That particular table is required for many parts of WordPress to function correctly.
These errors are certainly not related to your choice of theme unless there's something seriously defective about the theme you're using.
I suppose your error log size tops out at 4GB per day because of some file-size limitation somewhere in your system.
How can you fix this?
First, back up your site and your MySQL database.
Can you look at your MySQL database and see if the postmeta table has accidentally been renamed? If so, change its name back.
Do you know when this started happening? Do you have a backup from shortly before it started happening? If so, restore wp_postmeta from that backup.
Like #AdamErstelle mentioned, you may have a defective plugin. To me it seems unwise to use a defective plugin on a mission critical WordPress installation.
I was importing one table in a MySQL Server when the power went down. After this event I tried to query the table I was importing, but got the error 2013, only when I'm querying this table (the others work just fine).
I have physical access to the server, tried to execute any query from there (tried to SELECT, and even DROP TABLE) but still got the same error.
Does anybody know a solution where I can re-build only the table (without building the whole schema from scratch?)
I'm adding this as an answer rather than having lots of comments underneath. I must state in advance that I've not used MySQL but I have used SQL server a lot so I'm hoping that something I say may help.
You say the table is still there. Was it created as part of the operation you were doing or had it been there for a while?
What happens if someone else or a different account tries to access this table?
Is there anything on this page that is relevant to your problem?
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html