[Libreoffice-bugs] [Bug 121210] IMPORT: No possibility to set Auto Value to a Integer Primary Key when importing Calc range

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=121210

--- Comment #7 from Drew Jensen <drewjensen.inbox at gmail.com> ---
(In reply to Alex Thurgood from comment #3)
> I can confirm this with
> 
> Version: 6.1.2.1
> Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
> Threads CPU : 8; OS : Mac OS X 10.14; UI Render : par défaut; 
> Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded

In the Import Wizard (used to bring row data from an external source into a
Base table) though this inability to set a PK with an existing column was IIRC
a decision not an accident.

The ability is included, as you mention, to create an additional field for an
IDENTITY column in the target database table if the table is being created
during the current import session.

So why not include the ability to use a column of data from the source data? 

That discussion was now 14+ years behind us - // insert quote on aging 
so with human memory failings something along the lines of iirc

The import functionality was to begin with a limited amount of data
validation/manipulation capabilities. (I don't see where that has changed to a
significant degree) 

That a user may be dropping a collection of rows onto the application from any
number of applications/sources and the wizard should target the most basic
office software user. 

The first iteration of the Import Wizard when it came to physically importing
the data would display an error box should a row fail to import, offering the
user the two options; skip this record (with no explanation to why it failed)
and continue or quit the import process completely. 

OK - so lets look at an office software user who found some tabular data on a
website and copy a block of it. They paste that into Base and start the Import
Wizard. So they read a couple of articles, browsed a manual and watched a
video, they know it is good to have a primary key and they go about using what
looks like a good candidate in that data.

Some of these imports will fail for different reasons, with any unique indexes
created before the data is brought in the first time that number is going to go
up. The user didn't see why the insert of the row failed and maybe they just
gave up completely (not knowing not to use AUTOVALUE or set a PK checkbox for
this data) or maybe they sat and said toss out the row and keep going. 

Did we do them any favors in this scenario?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20181106/c9983af5/attachment-0001.html>