<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - IMPORT: No possibility to set Auto Value to a Integer Primary Key when importing Calc range" href="https://bugs.documentfoundation.org/show_bug.cgi?id=121210#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - IMPORT: No possibility to set Auto Value to a Integer Primary Key when importing Calc range" href="https://bugs.documentfoundation.org/show_bug.cgi?id=121210">bug 121210</a> from <a class="email" href="mailto:drewjensen.inbox@gmail.com" title="Drew Jensen <drewjensen.inbox@gmail.com>"> Drew Jensen</a> <pre>(In reply to Drew Jensen from <a href="show_bug.cgi?id=121210#c7">comment #7</a>) > (In reply to Alex Thurgood from <a href="show_bug.cgi?id=121210#c3">comment #3</a>) > > 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? My answer to that question is no, the best thing we could do for that scenario and the user was to nudge them to add an additional column for use as a PK in the new table and maximize the chances of bringing in all the rows of data they attempted to import.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>