Created attachment 41253 [details]
1 - Pasting data (records) from Calc into a Base table
We use Base a lot to insert data into databases via JDBC. We open a csv-file in Calc, select all records, copy them, open Base, and paste the records into a table. (see screenshots)
This opens up the "Copy data" dialog in Base. There are 2 simple enhancements that would improve our productivity a lot:
1. Make the wizard resizable
We often work with long field names that do not fit into the 2 columns of "Source table" and "Destination table". (see scr-shot 3) That makes it harder and more time-consuming to match the right fields. It would be great if we could resize that dialog, so that the 2 columns of "Source table" and "Destination table" would become larger. (and thus the field names would fit)
2. Make Base automatically match the columns by their name
Most of the time, the source & destination table have exact the same field names and the same amount of fields.
However, when the dialog opens, they are nog aligned. (see scr-shot 3) We have to manually align them, every single time.
It would be really helpfull if there was an option to automatically align fields with the same name.
For example by adding an option "Align source & destination tables by field name" in the first screen of the wizard. This could be placed for example under the option "Use first line as column names". (see scr-shot 2)
Created attachment 41254 [details]
2 - Wizard "Copy table", first screen
Created attachment 41255 [details]
3 - Wizard "Copy table", second screen
Thanks for the ideas.
> 2. Make Base automatically match the columns by their name
> Most of the time, the source & destination table have exact the same field
> names and the same amount of fields.
> However, when the dialog opens, they are nog aligned. (see scr-shot 3) We have
> to manually align them, every single time.
> It would be really helpfull if there was an option to automatically align
> fields with the same name.
It looks like the wizard does not do extra sort for source/destination field names. So I guess if the 'first row' in CSV is exactly the same with the table fields both in name and order, they are expected to align in the wizard. Could it be a workaround in your case?
the problem arises since both source & destination tables might have the same fields, but quite often they are not presented in the same order.
(for example: the csv contains them alfabetically because the export routine of some application does it that way, and the fields of the destination table (PostgreSQL) are presented in the order they were created in that table.)
As a result, they are not aligned in the window "Assign columns". (see scr-shot 3)
So we have to align them in the wizard
or in the csv before copy-pasting the info.
(Something we do over and over.)
1.Quick solution ?
A possible work-around would definitely be, to simply alfabetically sort all field names, in both the "source & destination table"-columns in the window "Assign columns".
That way, if both source & destination table:
- contain the same amount of fields,
- contain the same field names,
a simple sort would align them perfectally. (Thus resolving 90% of our problems!)
That would already be great. (In combination with making the window resizable for readability of longer field-names.)
2.An even more generic solution ?
Of course, if both source & destination table do not contain:
- the same amount of field names
- the same field names
the "quick solution" does not resolve the problem entirely.
field a field a
field b field aa
field bb field b
field c field c
field cc field d
field d field e
field e field f
field f field g
field g field h
An even more generic solution migth be to:
1. sort both source & destination fields (as in solution 1)
2. move all fields in both columns, that do not exist in the opposite column, to the bottom
That way, all linkable fields are linked together by means of their fieldname.
All not-linkable fields are shown at the bottom. Only those might have to be manually handled.
That would give in the example:
field a field a
field b field b
field c field c
field d field d
field e field e
field f field f
field g field g
field bb field aa
field cc field h
This way, the first 7 fields are already correctly linked in the wizard.
(Their checkbox can automatically be "checked" in the source table-column.)
At the end of both columns, we find the fields that could not be matched automatically. (Those could be "unchecked" automatically in the source table-column.)
I hope this explanation gives you more information and is readable.
If you would like extra info, don't hesitate to contact me.
"Solution 2" seems very good, but "Solution 1" would already be a time-saver.
Thank you for your time !
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
I created this issue for LibreOffice 3.3.0 RC1.
I can confirm this issue is still valid for LibreOffice 3.5.4 Build_ID 350m1(Build2).
This issue was created at the time for LibreOffice 3.3.0 RC1.
I have tested and can confirm this issue (enhancement) is still valid for LibreOffice 3.5.4 Build_ID 350m1(Build2).
I read the release notes for 3.6 and couldn't find any info regarding Base. So the issue should still be valid.
I reopened the bug, hoping someone can have a look at it. The wiki said "If you are an advanced QA member, feel free to do it yourself or help me and do it for me! "
The problem was, that your bug was in NEEDINFO state...
Please read this message in its entirety before responding.
Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed.
If you have time please do the following:
1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer).
2) If it is present please leave a comment telling us what version of LibreOffice and your operating system.
3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System
Please DO NOT
1) Update the version field
2) Reply via email (please reply directly on the bug tracker)
3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/.
Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Adding self to CC if not already on