duplicate row

BubikolRamios's profile image BubikolRamios posted 11 years ago in General Permalink
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's profile image BubikolRamios posted 11 years ago Permalink
Rewriten:

I think that timestamp value should not be copyed,
instead in new row, field of type timestamp should have current_timestamp.
ansgar's profile image ansgar posted 11 years ago Permalink
I'm sure there are users expecting the opposite, don't you?
BubikolRamios's profile image BubikolRamios posted 11 years ago Permalink
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's profile image TTSneko posted 11 years ago Permalink
"... 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).
[expired user #7929]'s profile image [expired user #7929] posted 10 years ago Permalink
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
[expired user #5213]'s profile image [expired user #5213] posted 10 years ago Permalink
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's profile image BubikolRamios posted 10 years ago Permalink
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.