Description: Issue -- Tables created from CSV connections cannot be structurally modified. If you need to add fields or create new tables, the CSV file has to be imported into a new Base database instead. There is no warning when importing a CSV file into Base that the resulting structure is READ ONLY. The user experience is misleading. Base gives the impression that: You “imported” a CSV You now have a table You can work with it like any other table But in reality: You created a connection, not a table The structure is locked The UI doesn’t warn you. The UI doesn’t explain the limitation. The UI doesn’t guide you to the correct workflow. I would recommend a warning or some sort of display that warns the user that if they are just importing a CSV file - that the resulting DB tables will NOT be editable and the resulting existing data CAN be edited - but you cannot add new records. If you truly want the structure to be database-like - you MUST import the csv data into an NEW database -- NOT use the import CSV routine which renders the structure READ-ONLY. Additionally, there is no key field identified in an import which essentially renders the existing data base structure almost useless from any further refinement. LibreOffice does give the impression that CSV import is seamless…and then quietly hands you a “table” that isn’t a real table. There’s no warning, no tooltip, no “by the way, this will be read‑only for structure.” Just a silent assumption that the user understands the difference between: Connecting to a CSV (read‑only schema, editable data) vs. Importing a CSV into a real Base database (fully editable) That distinction is invisible unless you already know the architecture. Steps to Reproduce: 1.Import a CSV file (let the software do the import -- not setting up a new DB first) 2. Import the data 3. Try to add fields to the table or try to add a new table to the database (it cannot be done) Actual Results: The resulting data in the tables that were generated can be edited; however, you CANNOT add any new records. You also CANNOT add any new fields to the tables. You also DO NOT have any key field identified in the new table(s). Expected Results: If you imported correctly -- the resulting DB structure SHOULD be editable. And if this does not change, then a WARNING should be given that IF you want to edit the new structure after a CSV import-- then using the CSV import WILL NOT work for your workflow and you need to instead -- Setup a brand new DB structure - and copy and paste the data into the new DB. Reproducible: Always User Profile Reset: No Additional Info: Give a warning or let people know that the resulting structure is a READ-ONLY DB.
For editing CSV there is Calc.
Sorry -- I do not mean to be disrespectful -- but after the CSV has been converted into the BASE program -- I should not have to go back to Calc to edit the data and then re-bring it in BASE. The whole purpose of making it a CSV and importing it into BASE in the first place was so that I could do data base operations on the data. I should be able to maintain the data (add, modify and delete) from within BASE. Every other DB program does this. For BASE not to do it is antiquated. But I digress. A simple warning message would be appropriate to let users know that the CSV import is NOT a true import - but a pointer, and if you want to do more with data AFTER the initial import - either edit the data in CALC and re-import, OR start a brand-new database and copy and paste the data in.
If you are importing a csv-file into an internal HSQLDB it will need a primary key for changing anything in the table. This is the warning of import wizard if there doesn't exist a primary key: "A unique index or primary key is required for data record identification in this database. You can only enter data into this table when one of these two structural conditions has been met. Should a primary key be created now?" If you import a csv-file into a dBase database connected to HSQLDB a primary key isn't needed. If you only connect to a folder with *.csv-files the tables will be write protected like they are write protected for Calc files or Writer files. This is the first paragraph of the Base wizard when connecting to csv-files: "Select the folder where the CSV (comma separated values) text files are stored. LibreOffice Base will open these files in read-only mode." The report doesn't show the database, which is used for the import of the csv-files.
Robert -- thank you for your comments. I must have missed that warning when I imported my CSV file. If this is the case -- I will let this drop. BUT -- realistically, to make this more user friendly, the messages should be a little clearer. Essentially, importing a CSV file is NOT a true import. As I said before, the user experience is bit misleading. Base gives the impression that: You “imported” a CSV You now have a table You can work with it like any other table But in reality: You created a connection, not a table The structure is locked The UI doesn’t warn you. (It might have as you said -- but it was not clear) The UI doesn’t explain the limitation. (This is for certain. If I am using any other database this is NOT a limitation). Essentially it may be a philosophical issue on my part. Since the limitation is there, rather than have the user fall into the trap - a little explanation would be nice-- 'If you want to import this CSV file for future maintenance (adds, deletes, etc.), best to NOT use the import -- start a new database and copy the data in.