distal-attribute
distal-attribute
distal-attribute
distal-attribute

duplicate row

BubikolRamios posted 2 years ago in General
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 ?
BubikolRamios posted 2 years ago
Rewriten:

I think that timestamp value should not be copyed,
instead in new row, field of type timestamp should have current_timestamp.
ansgar posted 2 years ago
I'm sure there are users expecting the opposite, don't you?
BubikolRamios posted 2 years ago
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.
TTSneko posted 2 years ago
"... 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).

tglx2011 posted 9 months ago
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
wouter_van_nifterick posted 9 months ago
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.
BubikolRamios posted 9 months ago
TIMESTAMP & default CURRENT_TIMESTAMP !

The only valid alternative would be if HeidiSQL didn't set any value at all for auto-filled fields



I agree.

+ the key fields values should be copyed. Now they are not.

Please login to leave a reply, or register at first.