I know Guid are randomly generated, Is there any way I can find out which one is latest Guid? As I have to get the latest inserted record in my table as my table has no timeContext column.
Thank you
No, you cannot get this information.
If you need information, such as when a row was inserted, then you need to add a column to your table to track that information.
If you're trying to mimic the "chained insert" style of inserts, where a row is inserted into one table, the IDENTITY() value is obtained, then used to insert into further tables, you can instead generate the Guid value before the first insert - indeed, it's one of the advantages of GUID identifiers that a whole set of related table changes can be prepared in isolation, without accessing the database at all.
Related
I am working with a existing database's table from another application. I want to query newly inserted records in a fixed interval.
Normally, in a table with AUTO INCREMENT id, I can store the last fetched id and use it in the query like WHERE id > :last_id. However, this table doesn't use AUTO INCREMENT id but use uuid as primary key. So is there any way to fetch new records only?
This DB is using MySQL. I can't change the database structure. The data size is quite huge so I don't think passing fetched uuids in query like WHERE uuid NOT IN (:fetch_uuids) will be a viable solution.
Edit:
There is created field, but unfortunately there is no warranty that the records with smaller created will be inserted first. So there is the risk of missing records using it.
The data were inserted by other application, and I only have read permission in this database.
Your question doesn't state whether there is a column containing the creation time of the record. If this exists then you could use this.
You have stated you cannot change the table structure, but are you sure you cannot add columns onto the existing structure? Your problem could be solved by adding an auto-increment 'secondary' ID and/or record creation timestamp. If you cannot modify the existing tables, could you perhaps create a new table with this additional information?
A solution to your problem may be in this answer. You may be able to either add an additional column to the existing table, or alternatively insert ids into a new table where you create an ID based on a TRIGGER from the original table
I'm trying to write a MySQL trigger for a table update (and a similar one for insert) that will take the updated columns and update corresponding columns in another table.
My set-up is this: I have one table (A) with several columns of numerical values and a record number Primary Key. I have another table (B) with identical column names but with short text descriptors that relate to each numerical value and also a record number as a Foreign Key referring to table A. Both of these tables may grow over time to include more columns - always matching each other - each with a simple predictable name (sticking with integers for now). All records are 1:1.
My hope was that I could write triggers for both update and insert on table A that would look at the numbers and, based on some simple logic, assign a descriptor to the corresponding record in table B (inserting that record in the case of the insert trigger). It got rather complicated quickly because I had to query INFORMATION_SCHEMA.COLUMNS to identify all current column names in table A, check each OLD vs NEW to verify that column was updated (for the update trigger anyway), do some logic to determine the appropriate descriptor, then INSERT/UPDATE the corresponding column in table B. I can't figure out how to set up a procedure/trigger that doesn't require storing column names in a variable to dynamically build an SQL statement. This is, of course, not allowed in a trigger and I have made some attempts at getting around this by moving the dynamic SQL statement into a separate stored procedure. None of this has worked and I've run into so many roadblocks, I'm coming to the conclusion that I'm going about this in entirely the wrong way.
Since I'm very new to database design, I just don't know what question to ask at this point other than, is there a better way or alternatively, is there a fix to my approach outlined above?
As always, I've searched thoroughly and not found any questions that answer mine but, if you see one that does, please point me that way!
When I insert data into a brand new table, it will assign a new id via AUTO_INCREMENT. So the first time I perform an insert I get an id of 1. However, if I delete the row and insert new data, the table acts as if there is still a preceding row (the new row will have an id of 2). This behavior concerns me because I feel like the data is still persisting somewhere. Any ideas of what it could be?
Your data is not persisting. MySql maintains a separate table about your table containing, among other things, the next auto-increment value for your table. You can reset this with:
ALTER TABLE tablename AUTO_INCREMENT = 1
However, be aware that if you are resetting to a value below another valid value in the table, you're asking for trouble.
you should simply use.
truncate table tablename;
So I'm designing a function that inserts a row into the MySQL database. The table has a Primary key with Auto-Increment enabled. So I don't insert the value of this column. But the PK is the only unique column of the entire table. How can I fetch the row I just inserted?
I don't see a problem if the function is in light traffic, but when its load is heavier and heavier, I can see a potential bug: say I inserted a row and the DB's AI value is 1, then before the fetch function starts to request the "latest inserted row", another row is inserted with the AI value 2. Now if the fetch function of Insert 1 runs, Row 2 will be fetched. I know the time gap will need to be so small to allow this bug to actually exist, but is there a better way to fetch the right row, while maintain the table only having the PK as the unique column? (I don't want to implement an additional checksum column, though I see it's a potential solution.)
its not very logical but you could:
insert into `table1` (`column1`,`column2`,`column3`) VALUES ("value1","value2","value3");
select * from `table1` where `PK`=LAST_INSERT_ID();
instead you should only SELECT LAST_INSERT_ID(); as jurgen d suggested and reuse the other data
Please read this php function mysqli_insert_id()
Sorry about the above, I foolishly assumed you were using php. MySQL also has a native LAST_INSERT_ID() function.
The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENTvalue generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
Reference; http://dev.mysql.com/doc/refman/5.5/en/information-functions.html#function_last-insert-id
I have an access database. In this I have a table which had an auto number field that created the ids. I somehow deleted these ids in the table. Now that I have deleted these records, I need a same sequence to continue (I want the deleted ids back in the table), but I am not able to do so because the auto number feature deleted the ids forever. I tried changing the field datatype to just number and entering the ids manually, but it won't change because the database gives me a warning saying that it is related to other features and I need to delete them first, something to do with relations. Please help me figure out a way to get the old ids in the table. The database is pretty complex, it doesn't just have one table, it has a lot of forms and reports and they are all intertwined. HELP!
Access will allow you to execute an INSERT statement which adds a row with an unused autonumber value.
INSERT INTO MyTable (auto_num_field, text_field)
VALUES (27, 'foo');
However if Access objects due to a defined relationship, you need to first drop the relationship, add the data, do whatever else is needed to satisfy the relationship constraint, and finally re-create the relationship.
OTOH, if you've already changed the field's data type from autonumber to something else, and you don't have a backup copy of the table, this could be even more challenging. We'd need more information to figure out a solution.