[mythtv-users] Recordedid conflict in attempted MythArchive import

[Stephen Worthington]

On Wed, 4 Jan 2017 17:14:45 +0000, you wrote:

>On Wed, Jan 4, 2017 at 3:16 PM, Stephen Worthington
><stephen_agent at jsw.gen.nz> wrote:
>> .... Then I
>> would need to read the new recordedid value back out of that new row
>
>[Generic MySQL answer follows]
>
>That would be, from the same mysql connection, doing
>something like:
>   select last_insert_id();
>The last_insert_id will be the (per connection) last inserted
>value for the auto_increment column.
>
>Note that things can get a bit more interesting if you are
>not using transactions, your connection can restart without
>your knowledge (perhaps due to layering), or you are using
>various shared connection techniques.  Exercise of appropriate
>caution is left to the implementer based on your needs to
>insure data and referential integrity.

Since I am not an experienced SQL coder and have never used
transactions, I was intending to be quite cautious about getting back
the new recordedid.  The recorded row has a basename field which is
almost as good as recordedid as a unique key, due to the way basename
is created by MythTV.  When recordedid was introduced, I did wonder
why basename had not been used instead of creating a new primary
index.  So I was intending to use basename to look up the newly
created recorded row and get its recordedid.