Bug 335154

Confirmed. The issue is related to the widget style used. It should be fixed, Kexi should work with any widget style on any graphical environment.

Created attachment 86750 [details]
view of kexi report design mode

This applies to the cleanlooks widget style.

Run 'kexi --style cleanlooks' to reproduce the bug.

Hmm confused the bug with https://bugs.kde.org/show_bug.cgi?id=335149. In fact the bug would be called like "Lack of Report Design toolbar".

Unfortunately I am unable to reproduce this one, with oxygen and eg. when I am using kexi --style cleanlooks.

@Ian Do you see the same issue when using oxygen style?

Hi.

I can confirm this bug is still apparent irrespective of whenthe oxygen or cleanlooks.

regards
Ian

@Ian Do you see this issue in Kexi 2.8.3? (I guess I need to first help you to build 2.8.3 using your source code-based setup)

right, Jaroslaw, I could try that this evening if I have detailed instructions on how to revert.

Ian

Jaroslaw,

We have no hope here, the situation has normalised. Whatever I open, whether on postgresql or sqlite, we have the toolbar back - sometimes!

I was trying to determine if the lack of the toolbar was specific to either an sqlite or a postgresql database. At the time it looked as if the behaviour was specific to the one postgresql database that I have - that is where the behaviour was found when first creating a new report. The various little databases I am testing under sqlite all showed the toolbar.

Returning to the postgresql database and attempting to create a report, we crashed. This has happened several times in a row. I sent a new bug report with details from the first crash.

However, I have now reopened, can look at an existing report in Design or open a new Design, and we have the toolbar back!

If I have another crash today I will send a new bug report, I see it checks automatically to see if this is a repeat bug.

Ian

I think you had better ignore that, sorry. I will get a pen & paper to hand to keep better notes.

In my 2 sqlite databases, opening a new Report in Design shows the toolbar.

In my postgresql database, opening a new Report in Design does not show the toolbar.

New Info.
An apparent repeat of this crash, with the crash handler window behaving oddly in that the kexi window was still open. When I finished with the bug report, which was not submitted, I carried on using kexi!

Ian

@Ian "In my postgresql database, opening a new Report in Design does not show the toolbar" - do you have any screenshot?

(asking because with postgresql database I see truncated buttons for the cleanlooks styles but the toolbar isn't completely hidden)

Jaroslaw, good morning.

the image attached to this bug report shows the postgresql example

Ian

OK, thanks. Set for 2.8.4. 

Isn't the current workaround like this? 
- create empty report, save it
- close and re-open

Created attachment 86982 [details]
view of kexi report design mode running postgresql with --style=oxygen

extra image showing same lack of toolbar while running under oxygen. the other image is of kexi running under cleanlooks.

Ian

jaroslaw,

Reply to comment 15.

Nope. The report where this bug surfaced has been opened-edited-saved-closed-opened many many times without causing the toolbar to appear.

To be sure I made a new  one-field report, and followed this procedure, but the situation remains the same for this as for the other report. I am in oxygen style for the record.

Ian

@Ian Could you try to create a new postgresql project with Kexi and try again?
If it works ok, then an SQL dump of at least kexi__* tables from the original pgsql project would be useful for me (private email is fine).

Jaroslaw,

I created a new database in postgresql (not a new table in the existing database).

Having created a table, then a matching form to get some population into the table, then a report, I can confirm that report design in this new database does show the 'Report Design' tab with relevant icons.

I now see that this bug seems related to my original database which stubbornly does not show the 'Report Design' tab. The new postgresql database and the sqlite database both allow normal Report design. 

I will organise an SQL dump soonest.

Ian

Ian

Jaroslaw,

What is the status here? I did send an original dump, but you said that it was not good (no data?) Was certainly a big enough file to have data. I did send another but not sure where we stand now except that I still have no toolbar in my main original postgresql project.

Ian

I plan to look, this week.  I am sorry for the delay.

commit bd6461d3b93eaaf8307a26520a24e757c0a8f1d1
now running.

thought I would check this bug out and on my postgresql database we have the design icons. Touch wood that this is permanent ;)

ian

commit 5513c16d57ac34933cb41da1419b437224f70d07
i am afraid it isn't
Report design toolbar not to be seen in postgresql  project.
:(
Ian

commit c4875b5037567eb4f56cc1c5e3842f17b694e4dd

report design toolbar still  not to be seen :(

I believe you :)

commit 556a8748a7109668106baf401b42e4a580da665d

report design toolbar still not to be seen in the original database reports - old or new :(
but ok in the sqlite and newly created postgresql ones

I need to add some fields to 'books' table so now plan that to drop the existing tables and recreate a new database from scratch will kill two birds with one stone as it were. This is not going to happen just yet, and I in the meantime I can & do work around this since i can manage with simple report requirements.

We're not done with this bug. It unfortunately takes more time. In the meantime if you re-create the database, data can be copied from the previous database by dumping it to an SQL script (in pgadmin?) and executing in a new database. Should work even if there are new columns in the new database assuming they don't have NOT NULL flags.

Hello, Jarosław,

Thanks for the tip about NOT NULL.

I didn't know that and have a script to add spare delimiters on
the end of a record as needed which does work fine.

Ian


On Sun, 21 Dec 2014 19:57:18 +0000
Jarosław Staniek <staniek@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=335154
> 
> --- Comment #27 from Jarosław Staniek <staniek@kde.org> ---
> We're not done with this bug. It unfortunately takes more time. In
> the meantime if you re-create the database, data can be copied from
> the previous database by dumping it to an SQL script (in pgadmin?)
> and executing in a new database. Should work even if there are new
> columns in the new database assuming they don't have NOT NULL flags.
> 


-----
Ian Balchin
Fables Bookshop, Grahamstown.

Cool. Future proof scripts can be used as follows:
1. Table T is (a int, b text);
2. You export data by generating script S such as:
INSERT INTO T (a, b) VALUES (1, 'foo');
INSERT INTO T (a, b) VALUES (1, 'bar');
..

Note the "(a, b)" explicitly specified.

3. Then if add columns so T is (a int, b text, c text) the script S will still work (as stated before, as long as the new column isn't NOT NULL. You can use the script as is, without appending extra empty values.

In contrast, CSV is less precise. In the future we'll want to have it possible to specify what column of CSV goes to what field on data importing. This specification could be also useful if it's saved somewhere.

The milestone is set 2.9, but more precisely it's most likely 2.9.x, x>0.

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.