-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when switching to "Browse Data" #2288
Comments
Ouch. Ok, you're welcome to email the database and project file to me (justin@postgresql.org), and I can forward it to whichever of our developers wants to pick this up. 😄 |
Just as a 'see what breaks', what happens if you create a copy of the database without the triggers, open the database (not a project file) and browse the data - is that all good? |
@th Thanks, received the files. I've just forwarded them to @chrisjlocke so he can experiment with them. 😄 |
👍 |
Well, its reproducible. The information from WinDbg isn't that hot though.
I might need a version that outputs debug info (preferably to a file and not the console though, as that doesn't work too well when running the actual application) When opening the project file, table 'submissions' shows no records (0 - 0 of 0) with no filters applied. By opening the database itself, it shows 1847 rows. Opening the project file, saving it, closing the current one and opening the new one has no effect. An integrity check of the database passed.
As another side note, open the project file, and it'll open. Immediately open it again and it'll crash. @th - If you open the database itself, all should be good. You can open more than one copy of DB4S at the same time, so work on the project file in one copy and browse the table in another copy. Not ideal in the slightest, but a hacky workaround until this is fixed. |
Been a while since I debugged Win apps, but...
... |
As a sidebar to this....
when running latest and switching from/to the Browse tab. It wasn't a priority for me at the moment and I was going to come back to root out the source. Seems relevant in these circumstances. |
Good point. I had tested with only the 32bit version of DB4S, but just tried again, and the crash still occurs if I use the 64bit version. |
Forwarded the database bits to @MKleusberg as well. 😄 |
Fix loading of project files with empty filter values. If an empty filter value was saved in a project file, it did not show up in the UI but was partially added to the query anyway. This lead to an invalid query with no results. Also fix a possible loophole which at least in theory could lead to an empty filter value being stored in the project file. See issue #2288.
Unfortunately it doesn't crash on my system. So it might be a Windows thing after all. I did however also notice that you don't see any rows in the view. This was because of some empty values for the filter in the project file and it's fixed now.I don't think this leads to the crash but it's still worth trying the next nightly build and see if that changes anything. |
I just tried the nightly (Windows, 64 bit, zip) from 2020-06-21, and everything works as expected on first glance. Thank you! |
@th Just to confirm... it's no longer crashing for you? |
That's correct. |
Awesome. 😄 @MKleusberg Good work. Sounds like we'd better include that patch in 3.12.1. |
Fix loading of project files with empty filter values. If an empty filter value was saved in a project file, it did not show up in the UI but was partially added to the query anyway. This lead to an invalid query with no results. Also fix a possible loophole which at least in theory could lead to an empty filter value being stored in the project file. See issue #2288.
@justinclift Definitely 😄 I've just cherry-picked the commit to the v3.12.x branch. |
Maybe associated (or I'm conflating issues): I tried latest (Linux x86_64) and the error message of |
@scottfurry Sounds like that string error needs further debugging work, to figure out exactly wtf is causing it. 😦 Not sure if it's this issue, but probably good to get it resolved from a safety point of view just in case? |
@scottfurry I can't reproduce this message. Can you maybe give me a step by step explanation of what you're doing and at what exact step the message appears. Maybe this helps narrowing this down even if it doesn't happen on my system 😄 |
@MKleusberg - Not doing anything fancy. |
When the index of the selected cell is invalid, i.e. no cell is selected, we cannot retrieve the font of the selected cell. Trying to look up the empty font name for updating the font combo box in the Format toolbar then fails, outputting a warning with some Qt versions. See issue #2288.
@scottfurry Thanks for the extra details! Can you check tomorrow's nightly build and see if the warning disappears? It's definitely a completely harmless warning though 😄 |
Still seeing |
Using latest repo master, this problem seems to have disappeared. I suspect that something done to resolve #2310 may have fixed this one. I'm good to close this if there is no objections. |
Is #2310 the right one? Looking at that, there doesn't seem to be any (even tentative) commits to fix it yet? |
Not sure exactly what but something in the last 3 days fixed it. |
Cool. 😄 |
Yep, that was the commit which I thought should fix it 😄 |
Details for the issue
What did you do?
Loaded my project file, which starts me in the Execute SQL view. Clicked on the Brose Data Tab.
I could share the project file (and SQLite database), but don't want to make it publically available on GitHub.
It's an SQLite database with less than 2000 rows. I have added a view that picks out about zero to thirty rows (depending on the current day):
CREATE VIEW eligible as SELECT * FROM entries WHERE date < date('now','-28 months') OR (date < date('now','-6 months') AND (leaveout = 'FALSE')) ORDER BY date ASC
I can query in the Execute SQL tab using SELECT * FROM eligible limit 2; without problems.
I also have two triggers:
CREATE TRIGGER eligible_change_leaveout
INSTEAD OF UPDATE OF leaveout ON eligible
BEGIN
UPDATE submissions SET leaveout=NEW.leaveout
WHERE id=NEW.id;
END
CREATE TRIGGER eligible_change_date
INSTEAD OF UPDATE OF date ON eligible
BEGIN
UPDATE submissions SET date=NEW.date
WHERE id=NEW.id;
END
What did you expect to see?
My data, starting in a view I have added and used previously.
What did you see instead?
The application crashes without any error message.
Useful extra information
The info below often helps, please fill it out if you're able to. :)
What operating system are you using?
What is your DB4S version?
Did you also
The text was updated successfully, but these errors were encountered: