Apache OpenOffice Community Forum

Hello to all, first post so please be gentle!!

I am creating a base project performing a loaning out function. I have 2 main tables, one contacts and one assets. I have created a form and subform on a loan "window". Main form is to select the loan item from the asset table and the subform drives a listbox driven from the contacts table.

What I am trying to do is copy the selected name from the listbox into the loaned to cell against the asset selected. So basically copy a name from contacts to asset.

I have tried various codes but can not seem to reference the listbox to retrieve the name in it.

Anyone any ideas?

Form name = Loan
ListBox = Name
I have created a text box called text to output the name to. Text is linked to the data "loaned to" in the asset table.

I hope that all makes sense!!

Thank you in advanced.

Welcome to the forum. Please forgive me if I fail fully to understand the problem or offer answers to the wrong question. Many thanks for warning that you are new to the forum, but does that apply also to Base and/or to the Relational Database?

If new only to Base, be aware that it is less developed than MS Access in that the List box in Base is a form control limited to entering or updating data: it is however wholly applicable to entering in one table data selected from another - particularly, where there is a one-to-many relationship between between the target table and the source table. Thus where

What I am trying to do is copy the selected name from the listbox into the loaned to cell against the asset selected. So basically copy a name from contacts to asset.

macros are not required and best avoided in Base: a good exposition and suitable solutions can be found at viewtopic.php?f=100&t=40444.

On the other hand if you are new to Relational Databases, any answer will depend on an understanding of its underlying design principles. For example, is the potential relationship between your accounts and contacts tables 'one-to-many', 'many-to-one', 'one-to-one' or 'many-to-many'? Before embarking on preparing forms for entering or updating data, sound design is essential for the database and for the references between tables. There are various tutorials and textbooks on the subject, but a useful introductory tutorial specifically related to Base can be downloaded from https://wiki.documentfoundation.org/ima ... torial.pdf. It may run to almost 200 pages but unlikely to be more than the subject requires.

Please come back if this reply merely confuses or if you have other questions, and if you are new to Base and/or the relational database please do not be discouraged - both are fascinating if at times frustrating challenges.

Thank you for your reply, got that bit sorted now! Still a bot more fiddling on other bits though, never ending!

I am new to base, however have had minor dealings with VB, Java, HTML, Access and even a bot of C++ however was never "fluent"!

Is there a way to create a new table from within a form by chance?

Is there a way to create a new table from within a form by chance?

Difficult to offer help without a clear understanding what type of 'table' is to be created. The description is often applied to the "Grid form control" which permits (selected) records from the database to be displayed by a form in a table format: like most other form controls the Grid form control can readily be added to any data form or sub-form.

The description is also applied to the means by which data is stored in the underlying database: [technically more correct to be known as a relation in accord with mathematical set theory]. Such tables cannot readily be created by Base from within a form: use either the options from its Tables window pane or direct SQL statements entered in the dialog obtained from the menu bar Tools>>SQL.

AOO Base, including its forms, is a quite distinct program from the referenced Database though in its embedded HQSL 1.8 version the two are rolled up together - in effect zipped - and saved as a single Base .odb file. A form in Base communicates with a database using SQL statements which the GUI generally hides from the user when the form is engaged in its primary function - the display or update of the quite separate underlying database data. Hence pushing the use of a form beyond its design remit may require resort to a macro: a route which should be treated with caution as seldom advisable or even required.