In OOo Base and Calc work well together and it is often beneficial to use Calc to perform complex calculations, including data pilot (pivot tables), on data stored in the database.

To export data from Base to Calc, first check that the database file has been registered in OpenOffice. Then open a new Calc spreadsheet and click f4. The "beamer" then opens above the spreadsheet showing all your registered databases. Open in the beamer the required database and table. It is then possible to drag and drop data as required from the beamer into the spreadsheet.

I don't suppose it's possible to move data back the other way from Calc to Base?

No, of course not. Like you can get a working spreadsheet from PDF or like you won't get the tooth paste back into the tube.
Databases have a structure. Spreadsheets are entropic, a bunch of cells with arbitrary content.

I don't suppose it's possible to move data back the other way from Calc to Base?

No, of course not. Like you can get a working spreadsheet from PDF or like you won't get the tooth paste back into the tube.

I take your point. However the question is not completely dumb, since after all it is possible to copy/paste from Calc to create a new Base table or add data to an existing one. Moreover, there are functions in Calc to allow parts of a sheet to work "like" a database. In principle then, if you can copy/paste into Base following a set of rules, why not set up a connection between a group of Calc cells and a Base table using similar rules?
But if you can't, you can't.

I don't suppose it's possible to move data back the other way from Calc to Base?

No, of course not. Like you can get a working spreadsheet from PDF or like you won't get the tooth paste back into the tube.

I take your point. However the question is not completely dumb, since after all it is possible to copy/paste from Calc to create a new Base table or add data to an existing one. Moreover, there are functions in Calc to allow parts of a sheet to work "like" a database. In principle then, if you can copy/paste into Base following a set of rules, why not set up a connection between a group of Calc cells and a Base table using similar rules?
But if you can't, you can't.

No, it is impossible to simply paste from spreadsheet. When the data do not match the requirements of the table you will have a lot of errors or a lot of clean up work due to inadequate field types.
When copy from Calc, I use to prepare a blank database table with all types, constraints and relations and then paste the Calc stuff.
IMHO this is the only way to get a clean database from the start.

Assuming you have a list of goods and you have to update frequently their quantities, how would you do?

I made a two tables db: the list of goods, and the list of processes for each good; I need to udpate goods quantity automatically at any process...

Thanks

Any database in this world, this forum, your preferred online shop, thousands of desktop apps distributed on CD, are made for this. I bet there is not one single database application where any kind of speadsheet is involved (except as export option).

For the outlined reasons, a spreadsheet cell can never be an input control for a database record. Databases store records (rows) as the smallest unit, spreadsheets store cell values. The cell positions are arbitrary. When you link some record set into a spreadsheet and then move/sort around the cells at will (anything goes on the huge empty cell grid) there is no way to find the respective row set in the database.
If you really want this to happen, you've got to store some meta-information for every linked spreadsheet cell, something like:
"Database Name",DECIMAL(9,2) FROM "Table X" WHERE "Primary Key Field"=8
That would be the required info to generate some SQL UPDATE query, triggered whenever the cell has been modified. Then you need some code to test if the modified value conforms with the database field type or not.
This would be far beyond the normal purpose of a spreadsheet.
Spreadsheets are mere calculation tools able to import all kinds of data from databases, clipboard and from many file formats.
Once you imported the data you can do whatever spreadsheets can do best.
The cell grid as user interface may be very common, compared with form controls it is third class. It is very easy to get some data in and out, but it can be very hard to get correct data in and out of a spreadsheet (as we can see any day on the Calc forum).

Spreadsheets have nothing in common with databases. OK, they deal with tabular data, somehow. But they do not even have a concept of tables, just rectangles of used cells on a empty grid that may be interpreted as tables, but then the table is only in the head of the user.
Often the used cells on a sheet have a layout that has nothing in common with the layout of a database table (items in rows, attributes in columns)._________________Rest in peace, oooforum.org
Get help on https://forum.openoffice.org

Assuming you have a list of goods and you have to update frequently their quantities, how would you do?

I made a two tables db: the list of goods, and the list of processes for each good; I need to udpate goods quantity automatically at any process...

Thanks

Any database in this world, warehouses, production lines, this forum, your preferred online shop, thousands of desktop apps distributed on CD, are made for this. I bet there is not one single database application where any kind of speadsheet is involved (except as export option).

For the outlined reasons, a spreadsheet cell can never be an input control for a database record. Databases store records (rows) as the smallest unit, spreadsheets store cell values. The cell positions are arbitrary. When you link some record set into a spreadsheet and then move/sort around the cells at will (anything goes on the huge empty cell grid) there is no way to find the respective row set in the database.
If you really want this to happen, you've got to store some meta-information for every linked spreadsheet cell, something like:
"Database Name",DECIMAL(9,2) FROM "Table X" WHERE "Primary Key Field"=8
That would be the required info to generate some SQL UPDATE query, triggered whenever the cell has been modified. Then you need some code to test if the modified value conforms with the database field type or not.
This would be far beyond the normal purpose of a spreadsheet.
Spreadsheets are mere calculation tools able to import all kinds of data from databases, clipboard and from many file formats.
Once you imported the data you can do whatever spreadsheets can do best.
The cell grid as user interface may be very common, compared with form controls it is third class. It is very easy to get some data in and out, but it can be very hard to get correct data in and out of a spreadsheet (as we can see any day on the Calc forum).

Spreadsheets have nothing in common with databases. OK, they deal with tabular data, somehow. But they do not even have a concept of tables, just rectangles of used cells on a empty grid that may be interpreted as tables.
Often the used cells on a sheet have a layout that has nothing in common with the layout of a database table (items in rows, attributes in columns).

Regarding you question on quantities, there are many solutions.
Have a look at my spontanious draft in Base:
Re: Using forms to add or subtract quantites from a table

Well, my database seems to be broken in version 3.2, even after rebuilding the database from script. Used to work fine in 3.0 and 3.1.
Embedded HSQLDB becomes more and more useless.

EDIT: Deleting the "Stamp" fields from tables "Input" and "Output" makes the DB usable. The time stamp is not needed to demonstrate the inventory._________________Rest in peace, oooforum.org
Get help on https://forum.openoffice.org