I have a procedure mst2 which creates a minimum spanning tree and updates a table MST in my database with several values. It works fine with WAMP but acts crazy when I try to import it on a live server.
Currently, every time I reload the table random values appear in it and seem to go up and down?? I have no idea what's going on. I'm not even calling the function but the table appears to be dynamically adjusting constantly.
I would post my code but it might be overkill, it's pretty extensive. If anybody has a general idea about what can cause this please let me know.
The problem was the fact that I was referencing the table in lowercase as 'mst' in some parts of the code relying on the fact that MySQL isn't case sensitive. Apparently the server I was importing to (Linux) had MySQL configured to be case sensitive for table (and possibly column?) names, fixing the table name in the code from lower to upper solved the issue.
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'm wondering if there is any better way than going through the tables one by one adding the columns missing when some fields/tables needs to be added because of the most recent changes in the app?
For example, I'm working at the localhost and when I finish doing the new version of my app, I will put all the files into my FTP and, sometimes, I have done, in my local database, changes and so it means that I also need to update my database at my server.
There's any better way to add/edit the columns/tables without changing the info? Some of the columns are also deleted, etc.
Hopefully you've thought your database design through so that making changes to the structure is a rare occurrence. If you're making regular changes to the number of columns or adding tables, it's likely a sign that you haven't normalized your database structure sufficiently.
Anyway, I'd script it as an SQL file that you deploy (which you can then run through phpMyAdmin or the command line or any other means you prefer to execute SQL queries). This has the added advantage of being something you can easily duplicate across your development and production databases, send to customers, and if you wish store in version control so you know when exactly you made the changes to the database.
This way, you'll end up with an SQL file that has a couple of statements like
ALTER TABLE `foo` ADD `new` INT NOT NULL ;
or something similar.
As for how you'd make the file, probably the easiest way is just copying and pasting the generated SQL statement from phpMyAdmin after modifying the table -- the SQL code used to make the change is shown near the top of the screen on the next page. You can copy and paste that to a new text file to create your SQL file. You may wish to add the first line
use `baz`;
using your database name instead of "baz". That way you don't have to specify on import which database the changes are meant for.
Hope this helps.
I have a database that I create through phpMyAdmin. Then I update it by creating tables in it via a script. All fine til now, then I use it. Two days later I drop this database altogether. Then I create another one with a different name, create something in it as well. Drop it too. Then I create a database with the same name as the first one, again creating tables in it. I leave it that way to find out that the next day I login I get the first database (with its contents) rather than the thing that I expected.
This type of weird behaviour happens no matter how you turn it. The same name is not the problem I think since I know it can happen with databases that carry different names. (I've tried it)
Basically it's like this thing forgets about it's state. What is happening? Any ideas?
This thing is driving me nuts since I can't do anything without fearing that I lose data.
I'm using windows with Zend Server.
I am NOT accidentally dropping tables or something like that.
EDIT: It seems that an immediate restart does not have any effect (meaning it keeps things as is, the random changes happen only after a certain period of time (more than a day)
Databases are stored on disk as folders containing:
one file describing the structure of each table
another file containing all of the tables' rows
one file for each index/key you define
some files (just allocated blocks) intended to allow storing large data such as text-columns or blob-columns which do not reside in the tables' rows (the rows only have a reference to where the blob resides).
When dropping a table the OS deletes some files. When dropping a database the OS deletes a folder.
It is possible (though very unlikely) that the database folder wasn't correctly deleted in the first place -- be it a permission issue on how you installed your server or a server bug or a phpMyAdmin bug.
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
When I export a table through SQLYog, the CREATE statement in the exported file lacks AutoIncrement on its primary key, even though the original table contained AutoIncrement.
Is this a bug (in Yog or in mysql?)? Should I report it?
How can I export the table with the AutoIncrement in place?
This happened to us also when using mysql from the command line. It turned out this happened because we added "skip opt" flag. The way to resolve is to either drop "skip opt" or add "--create-options" (Thanks Shlomo)
I just tried to reproduce this via SQLYog, and failed - so the problem must have only been presented in our custom dump scripts.
You should report it whether you think it's a bug or not. A cursory browse through online info gives no indication as to whether the loss of auto-incrementing columns is intentional or not.
And, if it's not specified one way or the other, I would be inclined to think that it should re-create the tables exactly as they were. This would be no different than if the export created a create table statement that left off columns starting with the letter X :-)
Raise it as a bug. If this is a genuine, documented restriction of the product, they will tell you, and hopefully point you to the documentation that details this. They'll probably also be able to tell you any workarounds that may fix it. They may state that it's because of some bone-headed decision from the MySQL people in which case you can then hit them with a bug report :-)
If it's actually a bug, good developers will be glad to hear about it so they can improve their product.