data view/rigt click/ duplicate row
If the source field is type of timestamp and default is current_timestamp, I think that value should not be copyed,
instead field new row should have current_timestamp.
The only reason I use duplicate row is to create new record where only some columns data are changed manualy, that is I think the purpose of it ?
duplicate row
Nope,I don't, as I said:
The only purpose of 'duplicate row' command is to manualy create new record , sparing some time not having to manualy insert some values, which are same for source and destination row.
New record means , at conditions stated in first post, that the date field of new row should be timestamped automaticaly (even if it is part of key).
Unless there is some other purpose of 'duplicate row' command
which I don't see.
The only purpose of 'duplicate row' command is to manualy create new record , sparing some time not having to manualy insert some values, which are same for source and destination row.
New record means , at conditions stated in first post, that the date field of new row should be timestamped automaticaly (even if it is part of key).
Unless there is some other purpose of 'duplicate row' command
which I don't see.
"... The only purpose of 'duplicate row' command is to manualy create new record ..."
That statement is actually a contradiction in terms: DUPLICATE ROW creates a COPY (a duplicate) of an existing row. If you want a NEW row, you use NEW ROW.
What you *WANT* it to do is to create a copy of an existing row whilst the copy process itself then checks and updates certain DEPENDENCIES, e.g. the status of "current_timestamp". That is a completely different and complex matter. Not every user needs that - in fact, many users, applications or cross-table situations do not want/allow data to be automatically altered (e.g. because it may corrupt cross-table data integrity).
That statement is actually a contradiction in terms: DUPLICATE ROW creates a COPY (a duplicate) of an existing row. If you want a NEW row, you use NEW ROW.
What you *WANT* it to do is to create a copy of an existing row whilst the copy process itself then checks and updates certain DEPENDENCIES, e.g. the status of "current_timestamp". That is a completely different and complex matter. Not every user needs that - in fact, many users, applications or cross-table situations do not want/allow data to be automatically altered (e.g. because it may corrupt cross-table data integrity).
I have a lot of fields in table (e.g. 50). I hide some of them. When I duplicate one record (for testing, to have data) the hidden columns filled with data is copied with "" (empty string), not the original data.
E.g
field1 field2 f3 f4
value=a b c d
if I hide the fields f2 and f3 and I duplicate the row, I will have
a b c d
a d
PS: I use HeidiSQL 8.3.0.4694
E.g
field1 field2 f3 f4
value=a b c d
if I hide the fields f2 and f3 and I duplicate the row, I will have
a b c d
a d
PS: I use HeidiSQL 8.3.0.4694
Copying the timestamp upon duplicating is fine as it is.
Duplicating takes place entirely in the client, and your timestamp needs to be generated by the server.
Think about it. What you're asking cannot be done.
Step1: duplicate a row.
Step2: let the server generate the timestamp. that can only be done properly by posting the data.
but wait, you didn't modify anything in the duplicated row. Now you have incorrect data in your table, and you're still editing it.
The only valid alternative would be if HeidiSQL didn't set any value at all for auto-filled fields, so that the server can generate it upon posting the changes.
But that's in theory.
In practice, the current method makes sense to me.
Duplicating takes place entirely in the client, and your timestamp needs to be generated by the server.
Think about it. What you're asking cannot be done.
Step1: duplicate a row.
Step2: let the server generate the timestamp. that can only be done properly by posting the data.
but wait, you didn't modify anything in the duplicated row. Now you have incorrect data in your table, and you're still editing it.
The only valid alternative would be if HeidiSQL didn't set any value at all for auto-filled fields, so that the server can generate it upon posting the changes.
But that's in theory.
In practice, the current method makes sense to me.
Please login to leave a reply, or register at first.