Emmanuel,

I kindly ask you to refine your description :)
I'm pretty sure that the online help does describe a lot of DnD
mechanisms, even in the database access area, there might be quite a
few. Okay, I did not check this :)
My point is that your current description requires the reader to guess
what you are doing, and forces it to check what the online help
describes. If you'd please describe what exactly you are doing, what
you expect to happen, what happens though you don't it expect :), what
does not happen, and so on, then this would help a lot.
This, additionally, would have the advantage that the description can
stand for itself - at the moment, it depends on a external resource
(the online help) not changing.

But before you do this, please check if issue 3045 is what you mean -
I strongly suspect this from what I guessed from your description :)

Thanks
Frank

[ description refinement ]

Uh ? I was aware of only one, namely clicking on the upper left corner
of the table data window in order to slect the table data, then
dragging with the left mouse button pressed to the writer window. This
pops up a dialogue box in which you can select the attributes
(columns)you wish to insert and the way you wish them inserted (import
to table, to fields or as raw text);  in order to terminate your
selection and have the data inserted in your writer document, you
click the OK button of the dialogue box.


[ ... duplicate of 3045 ? ]

Well, ... yes and no! My report of what happens is indeed close to the
description given in 3045, but there is a large difference: the
mechanism is functional with spreadsheet-based or JDBC-accessed
PostgreSQL databases, but not with ODBC-accessed databases. Therefore,
it does not look as a pure writer bug, but rather as a database-
related (probably ODBC- related) problem. Since I have found several
problems related to ODBC-accessed PostgreSQL databases, I wink that
they may have a common cause. 

Emanuel,
I admit I did not look into the help, so I do not know what's actually
in there. But you can drag the whole table, rows only, columns; and in
all cases there exist two modes (differentiated by pressing modifier
keys).

For the duplicate: issue 3045 does state nothing about spreadsheets
and so on, but only tells about the functionality not working with
PostgreSQL-ODBC. So where's the difference?
The more as other bugs (which had been flagged as duplicate of bug
3045) then describe the same as you here: _not_ working with
PostgreSQL-ODBC, but with anything else. So I really like to mark this
here as a duplicate ....

for not finding the issue: No need to argue (TM). Searching Issuezilla
is a pain, IMVHO.

you're right, I forgot to specifies that selecting only some rows does
not change the problem. I was not aware of the existence of modifier keys.

However, my report, in my opinion, pinpoints the problem at the
ODBC-access level; there might well be other,  writer-related
problems, but this one is database- specific. Does this grant the
existence of a separate report ? I do not know, but I would really
like to see it flagged as a database issue, more specifically
ODBC-related.

Emmanuel,

okay, for the moment let's keep aside the component (below ...).

issue 3045 says "can't do the DnD thingie with PostgreSQL-ODBC in a
Writer document on Linux, but into Spreadsheets it works".

issue 4811 (this one here) says "can't do the DnD thingie with
PostgreSQL-ODBC in a Writer document on Linux, but with JDBC the same
thing works".

Is this correct?
This alone would not justify a separate issue. Both descriptions do
not contradict, and as long as nobody proves that both issues are
different, we have to assume that they are the same (because it has a
high probability, imo). Instead, the usual way is to mark as
duplicate, and, if you wish, add the additional information to the
original bug.
So 3045 would then be "can't do the DnD thingie with PostgreSQL-ODBC
in a Writer document on Linux, but into Spreadsheets or connected to
the same with JDBC it works".

I simply see the problem of uneccesary bugs. 3045 and 4811 very much
sound like the same, so I see no reason in keeping them different, and
the (ver probable!) set them to "fixed" at the same time.


Now for the component:
Well, "component" in general is difficult. I pretty much assume that
the bug is _also_ located in the writer. In the scenario described, we
act as client providing functionality for the Writer, and the fact
that (nearly) the same client role works perfectly in Calc suggests
that part of the problem is located in the Writer.
On the other hand, there is some chance that the ODBC bridge has a
problem with the PostgreSQL-ODBC driver, which is uncovered in Writer
only. Wouldn't really surprise me.
The reason why I originally assigned 4811 to Writer (besides that I
suppose part of the problem is there) is that investigations have to
_start_ there. Normally, we would need something like "Database/Writer
interaction" :). But we haven't, so we have to decide for something ...

Okay. I admit my argueing for the "Word processor" component may have
been inspired by the technical background. From a user's perspective,
it's likely that user's recognize this as "Database Access" bug
instead. So I would agree to change the component field of 3045 back
to "Database Access".

But _then_ 4811 really is a duplicate, isn't it? :)

[ Edited transcript of my mail answer, as requested by F. S. ]

>Emmanuel,
>
>okay, for the moment let's keep aside the component (below ...).
>
>issue 3045 says "can't do the DnD thingie with PostgreSQL-ODBC in a
>Writer document on Linux, but into Spreadsheets it works".
>
>issue 4811 (this one here) says "can't do the DnD thingie with
>PostgreSQL-ODBC in a Writer document on Linux, but with JDBC the same
>thing works".
>
>Is this correct?
>This alone would not justify a separate issue. Both descriptions do
>not contradict,

Right.

>                and as long as nobody proves that both issues are
>different, we have to assume that they are the same (because it has a
>high probability, imo).

Wrong, IMNSHO.

3045 states that, with the same data source (namely an ODBC-accessed
PostgreSQL database), one can drag-and-drop INTO a speadsheet, but not
into a text. This tells us that writer has an issue with getting data
that calc has not. Therefore, it could be a problem into either writer
code or writer UI.

On the other hand, 4811 tells us that one can DnD into  text FROM a
JDBC-accessed PostgreSQL database or FROM spreadsheets accessd through
the database interface, but not FROM an ODBC-accessed PostgreSQL. Now,
this tells us that something differs between ODBC access and other
access(es ?).Therefore, something is wrong in data access mechanism
from ODBC that is not wrong in either JDBC-access or
Spreadsheet-through-database interface.

Now, it might well be teh case that there is indeed a bug in writer UI
or writer code that shows *only* in the case of ODBC access. But this
would be sufficient to demonstrate that what data-access presents to
the client application (writer, in this case) is different in the ODBC
case that it is in the JDBC or Spreadsheet cases. This lack o
uniformity is, in itself, a bug (or a misdesign), and it is related to
data-access mechanism. Q.E.D.

>                        Instead, the usual way is to mark as
>duplicate, and, if you wish, add the additional information to the
>original bug.
>So 3045 would then be "can't do the DnD thingie with PostgreSQL-ODBC
>in a Writer document on Linux, but into Spreadsheets or connected to
>the same with JDBC it works".

IMHO, no. See above.


>I simply see the problem of uneccesary bugs. 3045 and 4811 very much
>sound like the same, so I see no reason in keeping them different,
>and the (ver probable!) set them to "fixed" at the same time.

Not so probable, IMHO. See above.

>Now for the component:
>Well, "component" in general is difficult. I pretty much assume that
>the bug is _also_ located in the writer. In the scenario described,
>we act as client providing functionality for the Writer, and the fact
>that (nearly) the same client role works perfectly in Calc suggests
>that part of the problem is located in the Writer.

You might well be right. But, IMHO, this demonstrates the existence of
TWO* problems, on in data-acces mechanism, and one in Writer.


>On the other hand, there is some chance that the ODBC bridge has a
>problem with the PostgreSQL-ODBC driver, which is uncovered in Writer
>only. Wouldn't really surprise me.

Hmmm ... That would be a *third* bug, in the specifics of PostgreSQL
ODBC mechanism, i. e. the ODBC driver.

This, of course, is possible. However, other checks show that at
least, the basic ODBC mechanisms are working well in this driver. To
test this : install, for example, the R statistical software package
and the RODBC packge, which provides ODBC access to R.

[ Digression, but see below ... ]

This is, BTW, the way I have been able to pinpoint another data-access
problem to PostgreSQL databases through ODBC (see issue 4767 : no
distinction between table and views in database Beamer).

In R with RODBC, one can launch arbitrary SQL queries and some
selected ODBC operations ; one of them is "List tables", which returns
(as specified) a table of all tabes and views in the database. One of
the columns of this table is a field specifying if the table is indeed
a table, a system table or a view.

One can easily demonstrate that this information can be correctly used
by OpenOfice : in the "Tables" tab of the "Mmanage databases" tool, on
can see that tables are marked with a small "table" icon, whereas
views are marked with an icon bearing a broad arrow through them. By
the way, the data interface of StarOffice 5.2 did not have this problem.

[ End of digression ]

The previous example shows that some changes made in the ODBC-specific
data interface portion of OpenOffice have been done with
inconsistencies WRT the rest of the packges. I think that the problem
I reported in 4811 is specifically a data interface problem. I am also
of the opinion that this problem might trigger the bug reported in
3045, but I am not very sure of this.

>The reason why I originally assigned 4811 to Writer (besides that I
>suppose part of the problem is there) is that investigations have to
>_start_ there. Normally, we would need something like
>"Database/Writer interaction" :). But we haven't, so we have to
>decide for something ...

Again, two separate issues.

>Okay. I admit my argueing for the "Word processor" component may have
>been inspired by the technical background. From a user's perspective,
>it's likely that user's recognize this as "Database Access" bug
>instead. So I would agree to change the component field of 3045 back
>to "Database Access".

>But _then_ 4811 really is a duplicate, isn't it? :)

I'm afraid not ...

Sincerely yours,

                    Emmanuel Charpentier

I haven't any possibility to delve into source code ;  therefore,
since  IssueZilla wants me to reassign this issue, I am assigning it
to the owner of DB component code.

See recent comment in Issue # 4767 : I feel more and more that both
issues are related to a "middleware" problem in the new-and-shiny data
interface.

Emmanuel,

I'm still not convinced that this issue is not the same as issue 3045,
but I didn't yet find the time to react on your agueing.
For the moment, I grab this issue for myself (it was assigned to you
to ask to to give some more info, not to dig into the source :).

Frank

Fixed in next release.

closing

change subcomponent to 'none'