Re: [libreoffice-users] Re: Command line (convert) parameter(s)

[Stephan Zietsman]

NoOp wrote:
> Not sure about Windows, but here is the output of the '--help' command
> in linux. I suspect that the same commands are also available in Windows.
   

Thanks NoOp, that's what I was looking for.  The message window I
described only lists the options up to "-infilter=" along with
its description.  I suspect that the message window just truncates the
text at some arbitrary value.

Tom wrote:
> I think on Windows you can "pipe" commands although it's a bit different from
> gnu&linux or bsd.  I htink there is a way of piping output into a text-file 
> but
> i don't know how.  This might work tho
>
> soffice.exe -? | more

The "|more" option does work when listing help for other types of
commands (such as "help |more"), but unfortunately it doesn't work in
this case.  The main difference in this case is that the help text is
not echoed to the prompt (terminal), but it is rather displayed in a
message pop-up, which truncates (cuts off) the text at some point.

Nuno J. Silva wrote:
> Lee, try with only one dash. (Yes, I'd not expect only a single dash for
> long options, but it seems that this was, until recently, the way
> LibO/OOo did it.)

Just for interest's sake, on the Win7 system I'm using (running
LibreOfficePortable 3.3.2), the help options specify single dashes,
not double dashes.  Not sure if it is OS or LibO-version specific.

Regards
Stephan

-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-users] Re: list boxes not stable

[Tom Cloyd]

On 06/23/2011 06:21 AM, Andreas Säger wrote:

Am 22.06.2011 09:59, Tom Cloyd wrote:

My list box disaster just don't quit.

To this point, I've learned that the only quick, simple way to get a
list box onto a form is to use the list box wizard. Last night it
worked. Tonight it worked. Then, it stopped.

I now have a form with 5 list boxes. Three have spontaneously, quite
without reason, disabled themselves. They passively display the value in
their source table pointed to by the key value in the linked main table
fie.d. BUT, the display is now a ghostly gray. I have had to change the
background color just to see it at all. They also no longer are a part
of the tab order and you cannot click into them at all. Also, the drop
down no longer works at all. It is now just a data display field, not a
list box. Worthless. I have poured over their properties for over an
hour, trying to find the problem. No luck.

Another formerly working list box appears still to work, but will not
update the main record field to which it is linked (this is the problem
I was having last night, before I started using only the wizard to make
list boxes).

Finally, I find that I can no longer CREATE functioning list boxes,
using the wizard, which puts me out of the list box business altogether.

I just rebooted, hoping it might help, but it didn't (small chance!).

You can download this troubled database for examination HERE
. Look at the
"storage containers > items" form.

You'll see that my subform is working fine, The three brown-background
list boxes are now duds. The "quadrant" list box appears to work but
actually does nothing to the main table. The "macro-container" list box
is recently created, and does exactly what the brown boxes do: nothing.

Any ideas, anyone?





This type of database uses to work very well for me, particularly the 
list boxes use to work flawlessly.
Your relations appear somewhat messed up (at least unclear to me). 
This may impose some difficulties entering valid data.

Each container is of one type, thus the 1-n relation.
Each of the items belongs to one container, but the form design 
indicates that you want many of the same items distributed in 
different containers. So you need a list of containers, a list of 
items and an inventory list mapping many item-IDs to many 
container-IDs. The mapping table constitutes the subform with a column 
filled by list boxes so you fill many different items into the main 
form's selected container (see my example file linked in the other post).
Each room belongs to one container, I think. But why does it share the 
same foreign key with a location table? Is there a location (place) in 
the room or is it the geographical location of the whole container?


The main cause of your list box problem is that your main form is 
based on a view. Views are always read-only.


[Tutorial] Read-Only in Base :
http://user.services.openoffice.org/en/forum/viewtopic.php?f=83&t=26448

Base is very picky in this respect. But with the given tool set it is 
always(?) possible to get a writable main form from one table and as 
many writable subforms as needed so you can edit arbitrary complex 
relations across table boundaries.

Andreas,

I am grateful for your post, which I encountered at a particularly 
interesting time.


Considering the possibility that the suggestion made by someone else 
that LO base had become corrupted (in other words, that regressions had 
appeared) as a result of the transition from Open office to LibreOffice, 
and that with no dedicated Base programmer on board with Libreoffice we 
weren't likely to get a fix quickly, I just installed OpenOffice on 
another computer, and verified that I COULD get a view to supply data to 
a list box, as long as the main table involved was not a view. I took 
this to be the behavior BEFORE the transition to LibreOffice.


I was preparing to have both LO and OO installed on all 3 of my 
computers, and use the latter for Base work. Not an entirely happy prospect.


Then I saw your post, and verified that the behavior I just saw in OO is 
also in LO: I CAN have sorted tables (views) supply data to list boxes, 
as long as the underlying main form is a table, not a view. Sorted list 
boxes are a necessity for my database applications.


So...I can now simply go ahead with using LO. A great relief.

Now the priority is to get the documentation to be specific as to how to 
make this thing work. That said documentation did not so spell things 
out was the cause of my great chase through the wilderness in recent 
days. This need not have happened.


We don't need to fix the program - just the documentation.

Andreas, thanks again (and thanks too for all others who have stuck with 
me through this journey).


Tom Cloyd, MS MA
t...@tomcloyd.com
(435) 272-3332
St. George/Cedar City, Utah

--
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems uns

Re: [libreoffice-users] Re: BASE: bug in table designer

[Tom Cloyd]

OK. I'll leave it be. Have far bigger fish to fry...

t.

On 06/25/2011 04:17 PM, Alexander Thurgood wrote:

Le 24/06/11 21:37, Tom Cloyd a écrit :

Hi Tom,


Thanks for this thorough investigation of the behavior I described. I'm
glad it was replicated. I don't think this problem is (for me anyway)
much of an impediment, but I HAVE noticed other problems with default
values. To wit: default values set up in the table designer, do not
appear in forms when a new record is created and the table field is
linked to list box. The list box display remains blank. This happens if
the default value is in the table, OR if it's set in the list box
properties. Neither has any effect in the form, not even when the
table/view browser (press F4 to get this) is active.

Known behaviour, and this is actually currently by design (well it was
designed by the people at Oracle). The table/field creation
functionality does not transmit default values to the underlying
database, you are supposed to use a corresponding form for this and
define the default there rather than at the database level. This was
done because it was felt it was too difficult (i.e. developer time
intensive) for OOo to be able to manage all of the possible driver
return handling for all of the various possible database connections out
there. However, it does appear that even the form based default setting
of values does not work as intended, i.e. the values are not necessarily
passed from the form to the underlying db...File a bug, if you like, but
I'm pretty sure one has been filed already.


Alex





--
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

RE: [libreoffice-users] Re: Problem with paths

[Dennis E. Hamilton]

You may be running up against a permissions problem on Windows XP.  Are you 
running from an administrator account (something too many distros assume)?  If 
that's not it, it may be very difficult to troubleshoot.

For example, the portable build may be attempting to store the settings 
somewhere that is read-only or denied-access and not reporting (or not even 
checking) that the write is failing.

You may also be running into a Windows trick that diverts the write to a 
different "shadow" place,  so the application succeeds, but the restarted app 
can't find them.  (I can't remember if that was new with Vista or it made an 
appearance in one of the XP Service Packs.)

 - Dennis

-Original Message-
From: planas [mailto:jsloz...@gmail.com] 
Sent: Sunday, June 26, 2011 20:14
To: users@global.libreoffice.org
Subject: Re: [libreoffice-users] Re: Problem with paths

On Sun, 2011-06-26 at 13:49 +, Herbert Fromme wrote:

> > > On 13/04/2011 12:01, Jeffrey Needle wrote:
> > > > Hello, everyone. I'm using the portable build of LibreOffice from
> > > > portableapps.com on a WinXP system.
> > > >
> > > > I'm trying to change the documents directory that LibreOffice uses. I
> > > > go to Options, Paths and change the documents path. I click OK. I
> > > > close LO, reopen it, and the change to the path is lost. I can't find
> > > > any way to get the change to the path to stick. Is this a known bug?
> > > >
> > > > Thanks.
> 
> I have exactly the same problem, changes to paths don't stick. After closing 
> and
> reopening Libre Office, the changes have been lost.
> 
> Any ideas?
> 
> HF
> 


-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-users] Re: Problem with paths

[planas]

On Sun, 2011-06-26 at 13:49 +, Herbert Fromme wrote:

> > > On 13/04/2011 12:01, Jeffrey Needle wrote:
> > > > Hello, everyone. I'm using the portable build of LibreOffice from
> > > > portableapps.com on a WinXP system.
> > > >
> > > > I'm trying to change the documents directory that LibreOffice uses. I
> > > > go to Options, Paths and change the documents path. I click OK. I
> > > > close LO, reopen it, and the change to the path is lost. I can't find
> > > > any way to get the change to the path to stick. Is this a known bug?
> > > >
> > > > Thanks.
> 
> I have exactly the same problem, changes to paths don't stick. After closing 
> and
> reopening Libre Office, the changes have been lost.
> 
> Any ideas?
> 
> HF
> 
> 
> 


Which version of LO are you using and OS. I have changed the default
directory in LO 3.3.2 successfully in Linux. I am not familiar with the
build from portableapps.com.
-- 
Jay Lozier
jsloz...@gmail.com

-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-users] Re: Bug\feature in LO Base master\slave form linking

[planas]

Vladimir,

On Sun, 2011-06-26 at 16:57 +, Vladimir Drobyshevsky wrote:

> Have a nice day, Jay!
> 
> 
> planas  gmail.com> writes:
> 
> > 
> > Hi Vladimir,
> > 
> > ...
> >
> > > Is it possible to change the way of LO making relation's query or to
> > > find an another way to solve my problem?
> > > 
> > > Thank you in advance!
> > > 
> > > P.S. I have no subscription to this mailing list so send your answers
> > > to my address too, please!
> > > 
> > > -- 
> > > Sincerelly yours,
> > > Vladimir G. Drobyshevsky
> > > Wanna call me? Do it right now: +7 912 2473415
> > > 
> > 
> > My limited experience with SQL suggests you should qualify the typeID
> > fields to remove any ambiguity. I have had this problem when working
> > directly the outside database and developing queries for it. If one did
> > properly qualify the ambiguous fields you get a similar error message.
> > 
> 
> Thank you for answer!
> 
> You absolutelly right in your sugesstion, but WHERE clause is changed
> automatically (by adding 'AND "typeID" = :link_from_ProductID' ) by LO, as I
> wrote above. I would be very grateful if you can show me solution to change 
> it.
> 
> -- 
> Sincerelly yours,
> Vladimir G. Drobyshevsky
> Wanna call me? Do it right now: +7 912 2473415
> 
> 


I will show my limited experience I would not use ". The dialect I am
most familiar with does not normally use them. So my query would be
written:

SELECT invTypes.typeName AS Name,
invTypes.description AS Description,
invTypeMaterials.quantity AS Qty,
invTypeMaterials.typeID
FROM EDB.public.invTypes AS invTypes,
EDB.public.invTypeMaterials AS invTypeMaterials
WHERE invTypes.typeID = invTypeMaterials.materialTypeID

I am not sure if another dialect SQL requires the ".  I am looking at my
reference book SQL Server. I would think the dialects would not very
that much but I have surprised before.
-- 
Jay Lozier
jsloz...@gmail.com

-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-users] Re: using fields in a text document

[Alexander Thurgood]

Le 26/06/11 16:44, John B a écrit :

Hi John,


> 1) On re-opening The database lost its connection to the letter and you
> had a chore to re-link the data fields in the *.csv file to those in the
> letter.

Known bug.


> 
> 2) To add a "new contact" is too complex.
>

Known limitation. Calc Sheets/CSV files are read only when the file is
being accessed by the mailmerge, i.e. being used as a datasource, it has
been like this for years.



> 3) Merge, then adds all the fields again in bulk  to the letter for a
> 2nd time, so you have to delete all the 1st batch

Seem to recall that this too, is a known bug.


> 
> 4) I thought maybe it would be better then, to add new contacts to the
> csv file in Calc
> No problem there - up until you go back to Mail merge.
> it corrupts the file in some way (or the 2 are incompatible). All the
> 1st and last letters of any word are missing, eg, " company" becomes
> "ompan" and "zip" becomes "i", and it does the same to the data, then
> even when you merge you get nonsense data in the fields on the letter.
> Henceforth, totally useless.
> 

Also known bug, as far as I can remember.


Look up the bugs in freedesktop :

https://bugs.freedesktop.org/buglist.cgi?quicksearch=libreoffice+mail+merge


and also :

https://bugs.freedesktop.org/show_bug.cgi?id=34325




Alex


-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-users] Re: Bug\feature in LO Base master\slave form linking

[Alexander Thurgood]

Le 26/06/11 11:36, Vladimir Drobyshevsky a écrit :

Hi Vladimir,

> 
> Is it possible to change the way of LO making relation's query or to
> find an another way to solve my problem?
> 

The only thing I can think of is by turning off "ESCAPE PROCESSING".
This may be possible in the advanced connection parameters. What you
must know is that you might have found one of the known bugs in the SQL
parser that incorrectly removes parts of the query when you switch from
the graphical tools to direct SQL.


Alex


-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-users] Re: Bug\feature in LO Base master\slave form linking

[Vladimir Drobyshevsky]

Have a nice day, Jay!


planas  gmail.com> writes:

> 
> Hi Vladimir,
> 
> ...
>
> > Is it possible to change the way of LO making relation's query or to
> > find an another way to solve my problem?
> > 
> > Thank you in advance!
> > 
> > P.S. I have no subscription to this mailing list so send your answers
> > to my address too, please!
> > 
> > -- 
> > Sincerelly yours,
> > Vladimir G. Drobyshevsky
> > Wanna call me? Do it right now: +7 912 2473415
> > 
> 
> My limited experience with SQL suggests you should qualify the typeID
> fields to remove any ambiguity. I have had this problem when working
> directly the outside database and developing queries for it. If one did
> properly qualify the ambiguous fields you get a similar error message.
> 

Thank you for answer!

You absolutelly right in your sugesstion, but WHERE clause is changed
automatically (by adding 'AND "typeID" = :link_from_ProductID' ) by LO, as I
wrote above. I would be very grateful if you can show me solution to change it.

-- 
Sincerelly yours,
Vladimir G. Drobyshevsky
Wanna call me? Do it right now: +7 912 2473415


-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-users] Re: Problem with paths

[Herbert Fromme]

> > On 13/04/2011 12:01, Jeffrey Needle wrote:
> > > Hello, everyone. I'm using the portable build of LibreOffice from
> > > portableapps.com on a WinXP system.
> > >
> > > I'm trying to change the documents directory that LibreOffice uses. I
> > > go to Options, Paths and change the documents path. I click OK. I
> > > close LO, reopen it, and the change to the path is lost. I can't find
> > > any way to get the change to the path to stick. Is this a known bug?
> > >
> > > Thanks.

I have exactly the same problem, changes to paths don't stick. After closing and
reopening Libre Office, the changes have been lost.

Any ideas?

HF



-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-users] Bug\feature in LO Base master\slave form linking

[planas]

Hi Vladimir,

On Sun, 2011-06-26 at 15:36 +0600, Vladimir Drobyshevsky wrote:

> Hello!
> 
>   I'm trying to create a form with master\slave relation. My tables
> linked to external PostgreSQL database, so I'm getting data for master
> and slave forms from queries. I make the relation by choosing fields
> in "Link with master table" and "Link with slave table" (I have
> localized version so I don't know how it exactly named) properties in
> subform's Property Editor. Subform's query is:
> 
> SELECT "invTypes"."typeName" AS "Name",
> "invTypes"."description" AS "Description",
> "invTypeMaterials"."quantity" AS "Qty",
> "invTypeMaterials"."typeID"
> FROM "EDB"."public"."invTypes" AS "invTypes",
> "EDB"."public"."invTypeMaterials" AS "invTypeMaterials"
> WHERE "invTypes"."typeID" = "invTypeMaterials"."materialTypeID"
> 
> Relation has to be build by "intTypeMaterials"."typeID" field, so I'm
> choosing "typeID" for "table" intTypeMaterials" and "ProductID" for
> master "table".
> 
> When I'm trying to open the whole form in view mode, I'm getting an
> error: "Cannot load data. ERROR:  column reference "typeID" is
> ambiguous at character 338; Error while executing the query".
> If I look into the sent query, I will see that LO change WHERE clause
> to '( "invTypes"."typeID" = "invTypeMaterials"."materialTypeID" ) AND
> ( ( "typeID" = :link_from_ProductID ) )'.
> Both tables in query have "typeID" field, so server can't choose the
> need one. And Postgres can't use an AS aliases in WHERE clause.
> 
> Is it possible to change the way of LO making relation's query or to
> find an another way to solve my problem?
> 
> Thank you in advance!
> 
> P.S. I have no subscription to this mailing list so send your answers
> to my address too, please!
> 
> -- 
> Sincerelly yours,
> Vladimir G. Drobyshevsky
> Wanna call me? Do it right now: +7 912 2473415
> 

My limited experience with SQL suggests you should qualify the typeID
fields to remove any ambiguity. I have had this problem when working
directly the outside database and developing queries for it. If one did
properly qualify the ambiguous fields you get a similar error message.

-- 
Jay Lozier
jsloz...@gmail.com

-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-users] Re: using fields in a text document

[John B]

On 25/06/2011 20:32, lee wrote:

John B  writes:


I have tried the mailmerge facility in LO and I as yet cannot get
anywhere with it.

Hm, it's not too difficult to get to the point where you could finally
save, print or send your documents. Just make sure that there are no
unmatched fields. As someone described, you can even drag and drop
fields from a database into your document.

I could use mailmerge if it would reliably send the documents rather
than sometimes say "0 of 0 messages sent" despite there are two messages
to be sent --- and if the PDF created that way wasn't messed up. And it
would even be really useful if changing the "properties" when sending
documents as PDF would work rather than crash LO.

I use mail merge all the time - it is quick and a joy, so - I thought 
that I would have a real go at getting LO mail merge to work this weekend.


Mail merge unfortunately  turns out to be unacceptably fragile

I finally gave up on LO 3.4 after a couple of hours (plus the hours 
before that) - it just does not work


I uninstalled 3.4 and installed 3.3.3 - This worked fine the first time 
(and never thereafter) to make a letter with the inbuilt standard 
contact fields (Title, First name etc) and made up 4 contact details


I noticed that the contact list is saved as a "tab" delineated 
spreadsheet in *.csv format.


One useful feature is that mail merge auto posts all the fields onto the 
letter for you, you can then move them (or delete) to a position of your 
choosing


You can even copy & paste fields in the letter so that the same data can 
appear as many times as you like on the document where you need them.


All things at this point are good, excluding the fact that there is no 
navigation tool bar, hence you cannot just skip to the 3rd address or 
the 1st or last address whilst looking at the letter. Other than that, 
it worked exactly as it should. So if its a small, one off and you have 
made no mistakes - brilliant.


closed all down it was at this point thereafter all things went wrong:-

1) On re-opening The database lost its connection to the letter and you 
had a chore to re-link the data fields in the *.csv file to those in the 
letter.


2) To add a "new contact" is too complex.

3) Merge, then adds all the fields again in bulk  to the letter for a 
2nd time, so you have to delete all the 1st batch


4) I thought maybe it would be better then, to add new contacts to the 
csv file in Calc

No problem there - up until you go back to Mail merge.
it corrupts the file in some way (or the 2 are incompatible). All the 
1st and last letters of any word are missing, eg, " company" becomes 
"ompan" and "zip" becomes "i", and it does the same to the data, then 
even when you merge you get nonsense data in the fields on the letter. 
Henceforth, totally useless.


I thought that maybe 3.3.3 is not as stable as it should be, so I 
installed 3.2 and it is still the same (missing letters etc)


Mail merge should be so simple, intuitive and above all reusable.

If anybody gets this to work in a stable and repeatable way, please let 
me know.


Also without a WYSIWYG navigation tool bar large databases would be out 
of the question - you also need navigation for printing, as in practice 
you want to print the 1st letter (to check), auto skip to the 2nd and if 
the 1st one is OK then you print "print the rest" or you can print the 
next one (one at a time) until you get it right. LO does not have this 
facility.


One strange feature I noticed is that on save / print it merges and 
generates  (in my case) all 4 letters, I assume then if you had a 
database of 1 names you would have a file with 1 letters (to big).



John B
Xp Pro sp3
LO 3.4, 3.3.3 & 3.2






























--
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-users] Bug\feature in LO Base master\slave form linking

[Vladimir Drobyshevsky]

Hello!

  I'm trying to create a form with master\slave relation. My tables
linked to external PostgreSQL database, so I'm getting data for master
and slave forms from queries. I make the relation by choosing fields
in "Link with master table" and "Link with slave table" (I have
localized version so I don't know how it exactly named) properties in
subform's Property Editor. Subform's query is:

SELECT "invTypes"."typeName" AS "Name",
"invTypes"."description" AS "Description",
"invTypeMaterials"."quantity" AS "Qty",
"invTypeMaterials"."typeID"
FROM "EDB"."public"."invTypes" AS "invTypes",
"EDB"."public"."invTypeMaterials" AS "invTypeMaterials"
WHERE "invTypes"."typeID" = "invTypeMaterials"."materialTypeID"

Relation has to be build by "intTypeMaterials"."typeID" field, so I'm
choosing "typeID" for "table" intTypeMaterials" and "ProductID" for
master "table".

When I'm trying to open the whole form in view mode, I'm getting an
error: "Cannot load data. ERROR:  column reference "typeID" is
ambiguous at character 338; Error while executing the query".
If I look into the sent query, I will see that LO change WHERE clause
to '( "invTypes"."typeID" = "invTypeMaterials"."materialTypeID" ) AND
( ( "typeID" = :link_from_ProductID ) )'.
Both tables in query have "typeID" field, so server can't choose the
need one. And Postgres can't use an AS aliases in WHERE clause.

Is it possible to change the way of LO making relation's query or to
find an another way to solve my problem?

Thank you in advance!

P.S. I have no subscription to this mailing list so send your answers
to my address too, please!

-- 
Sincerelly yours,
Vladimir G. Drobyshevsky
Wanna call me? Do it right now: +7 912 2473415

-- 
Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org
In case of problems unsubscribing, write to postmas...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted