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.
Related
OS: W10.
This question is specifically about what's possible in MariaDB, specially version "Ver 15.1 Distrib 10.7.3-MariaDB".
Edit
From another SO site I have found that from 10.3.4 MariaDB does in fact implement "temporal tables". Not clear yet whether this provides a solution.
I want to implement a way of having a "last modified" timestamp for a database, i.e. which shows when the last INSERT or DELETE or UPDATE occurred, regardless of the table where it happened. I found this, which looked promising... but then some comments there about InnoDB and information_schema.tables.update_time led me to do an experiment.
Contrary to what is asserted in some places about update_time always being NULL in InnoDB tables, this does not seem to be the case with what I've got. Unfortunately, the comment there about this value being set to NULL whenever the server starts does appear to be true.
Elsewhere I read that newer versions of MariaDB, pulling away from vanilla MySQL, do in fact implement some sort of history of changes.
I'm currently working on the assumption that I shall have to implement an ON_UPATE trigger for every table, and then get values for each of these and find the most recent, in order to determine the "last modified" time for the whole database.
Is there any other possibility with this version of MariaDB?
Edit
In fact I have provided an answer which works for my use case on another SO site (when I added this link as an answer here that answer was then deleted by a mod - but in reality some might find it useful).
just make a table that has all the table names and a timestamp column.
then on the ON_UPATE trigger, just update the tablename record.
this way, you have central table which has the timestamps, dont do any hacks.
keep it simple.
use this
In my MySQL database I have a user table. I need to perform search as you type with typo over the user name field. There are few very old question on this topic. I tested the builtin full text search of mysql but it didn't work as expected (it does not handle typo) [I knew but I tried anyway].
What's my best option? I thought there should be an easy solution nowadays. I'm thinking about replicating the user table on elasticsearch and do the instant search from there, but I'd really like to avoid the syncronization nightmare that this will cause.
Thanks!!
You could use SOUNDEX for mysql. We have tried that but I can say that it does not work that well and it also makes the search a bit slow.
We Had a similar issue and switched to ES.
What we did is as follows:
Created a trigger for the table that will be synced to ES. The
trigger will write to a new table. The columns of such a table would
be:
IdToUpdate Operation DateTime IsSynced
The Operation would be create, update, delete. IsSynced will tell
whether the update is pushed to ES.
Then add a corn job that would query this table for all rows that will have issynced set to say '0', Add those ID's and operation to a Queue like RabbitMQ. And set the ISSynced to 1 for those ID's
The reason to use RabbitMQ is that it will make sure that the update is forwarded to ES. In case of failure we can always re-queue the the object.
Write a consumer to get the objects from the queue and update ES.
Apart from this you will also have to create a utility that will create an ES index from the database for first time use.
And you can also look at Fuzzy Search of ES that will handle typo's
Also Completion suggester which also supports fuzzy search.
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.
Just wondered if there was a secret to do something like Database.Security.Users like AdventureWorks DB is setup. Seems no matter what I do to try to setup "Security.Users", I always get the dbo in front of it and have a hell of a time in C# accessing the info. Am I doing something wrong?
Are you trying to create an object called Security.Users with a dot? (as opposed to Users in the Security schema?) That's probably best avoided as you're seeing, but if you are then the best way to quote the name is probably in square brackets, i.e. [Security.Users].
dbo is the default database schema name. Unless you've configured a different default schema for your users etc. you can usually just ignore it, although it's still needed if you're referencing another database by name.
you first need to create a schema and make that schema the default schema for that user. Examples and more info can be found here: http://msdn.microsoft.com/en-us/library/ms190387.aspx
If you are using the Wizard to create this, you will always get it. Write the SQL statements and you should be fine.
I'm trying to use a simple mysql database but tweak it so that every field is backed up up to an indefinite number of versions. The best way I can illustrate this is by replacing each and every field of every table with a stack of all the values this field has ever had (each of these values should be timestamped). I guess it's kind of like having customized version control for all my data..
Any ideas on how to do this?
The usual method for "tracking any changes" to a table is to add insert/update/delete trigger procedures on the table and have those records saved in a history table.
For example, if your main data table is "ItemInfo" then you would also have an ItemInfo_History table that got a copy of the new record every time anything changed (via the triggers).
This keeps the performance of your primary table consistent, yet gives you access to the history of any changes if you need it.
Here are some examples, they are for SQL Server but they demonstrate the logic:
My Repository table
My Repository History table
My Repository Insert trigger procedure
My Repository Update trigger procedure
Hmm, what you're talking about sounds similar to Slowly Changing Dimension.
Be aware that version control on arbitrary database structures is officially a rather Hard Problem. :-)
A simple solution would be to add a version/revision field to the tables, and whenever a record is updated, instead of updating it in place, insert a copy with the changes applied and the version number incremented. Then when selecting, always choose the record with the latest version. That's roughly how most such schemes are implemented (e.g. Wikimedia does it pretty much this exact way).
Maybe a tool can help you to do that for you. Have a look at nextep designer :
https://github.com/christophefondacci/nextep-designer
With this IDE you will be able to take snapshots of your database structure and data and put it under version control. After this you can compute the differences between any 2 versions and generate the appropriate SQL that can insert / update / delete your data.
Maybe this is an alternative way to achieve what you wanted.