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

duplicate row

User, date Message
Written by BubikolRamios
1 year ago
Category: General
326 posts since Thu, 14 Jan 10
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 ?
Written by BubikolRamios
1 year ago
326 posts since Thu, 14 Jan 10
Rewriten:

I think that timestamp value should not be copyed,
instead in new row, field of type timestamp should have current_timestamp.
Written by ansgar
1 year ago
4800 posts since Fri, 07 Apr 06
I'm sure there are users expecting the opposite, don't you?
Written by BubikolRamios
1 year ago
326 posts since Thu, 14 Jan 10
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.
Written by TTSneko
1 year ago
39 posts since Thu, 19 Jul 12
"... 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).
Written by tglx2011
4 weeks ago
1 posts since Wed, 26 Mar 14
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
Written by wouter_van_nifterick
4 weeks ago
14 posts since Wed, 06 Oct 10
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.
Written by BubikolRamios
4 weeks ago
326 posts since Thu, 14 Jan 10
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.