search

Sequel-Ace / Sequel-Ace

MySQL/MariaDB database management for macOS
https://sequel-ace.com
Other
6.76k stars 249 forks source link

Sometimes switches to random database on same database host (dropdown does not change) #1806

Open andersir opened 1 year ago

andersir commented 1 year ago

Is Issue Present in Latest Beta?

Description We are a number of people using Sequel Ace at my office - and I have been using since it was Sequel Pro. This problem has been there always - even in Pro as far as I recall.

We use a single database host with around 132 databases (that in itself is a problem when trying to find the correct database). Actually the 132 databases are 6 databases for 22 environments, so there are 22 identical databases (times 6), but of course with different data in them.

When using Sequel Ace I often have multiple tabs open toward different databases - but all of a sudden a tab connects to the wrong database. It will say the correct name in the database dropdown selector, but the data is from another database.

As I see it, it does not happen while I am working in Sequel Ace (but I am not sure), but more when my Mac has been locked or hibernated. Then when I run the same query as before - it fetches data from another database. A "fun" thing is that it also manages to switch to a database with the same database layout - as mentioned we have 6 different layouts multiplied to 22 customers.

Our database naming is (customerX is used instead of actual customer names):

cubs_customer1-production
cubs_customer1-production_and
cubs_customer1-production_noget
cubs_customer1-stage
cubs_customer1-stage_and
cubs_customer1-stage_noget
cubs_customer2-production
cubs_customer2-production_and
cubs_customer2-production_noget
cubs_customer2-stage
cubs_customer2-stage_and
cubs_customer2-stage_noget
...

So when it switches - it is always from e.g. cubs_customer1-production to cubs_customer2-production - I primarily work with the -production databases, so this is the only place I have seen the problem.

The switch might even be to a database not open in any of the other tabs.

Steps To Reproduce I am unable to reproduce it - but it happens often.

Expected Behaviour I would expect that I can trust the database name in the dropdown. This has been very close to cause critical errors because scripts were suddenly run on a different database then expected.

Related Issues

I have not been able to the related issues.

Additional Context My background is 35 years of working with computers as a systems developer.

If you need to to try out different scenarios - please let me know.

deanzod commented 1 year ago

I can confirm this is happening to me too on v4.0.6 (upgrading to 4.0.7 now to see if it goes away)

My experience is I have 3 or 4 db tabs open. After a while the data/content seems to randomly match other tabs. So db1 has all the tables and content from db3 and db3 has content from db4. Due to me usually having local, staging and production databases open it is hard for me to tell exactly which belongs to which

ArneAmeye commented 1 year ago

I'm experiencing this too lately, on 4.0.6 I started noticing this, upgraded to 4.0.7 version and still seeing this bug. Tabs get mixed up all the time, it's dangerous if you don't pay attention to it since you might be editing or export/import data that you did not expect to work with.

funaward commented 1 year ago

Yes, I also facing this issue. I have to downgrade to 4.0.5

llhwjj commented 1 year ago

Yes, I also facing this issue. upgraded to 4.0.7 version and still seeing this bug.

wolfswinkel commented 1 year ago

Also wanted to report the same issue. I don't know if I had the problem always but lately it is happening more (maybe because I use more windows with diffrent tabs open. What I have experienced so far that the other selected database is available within the list of db's. So for example I have 4 diffrent connections:

When connected to external 1 it won't show results of a database that could be opened in another window with a db opened from external 2. I don't know exactly if this could occur if I have 1 window with diffrent tabs that are connected to diffrent external servers. But that's just not the way I work. I seperate them so at max I have 4 windows opened (1 for local server and 3 with the external servers).

Is can get messy, because I've already imported a database that went into the wrong one... Thankfully I was local at the time. So I now mostly switch a tab to another db and then go back and only then I use delete or create queries.

eltigba commented 1 year ago

This is a very scary and dangerous bug. I've always relied on the colored tabs to sanity check the current env so I didn't even realize what was happening at first when a prod tab was visible instead of my selected staging tab. I have noticed that the window title text in the top left shows the tab that is actually active, but since that area is not color coded it is not obvious that something is not working as expected.

wrongtab3

funaward commented 1 year ago

currently use 4.0.5 instead of will works

cord commented 1 year ago

Same issue with 4.0.9 /Apps Store Version on Mac OS Sonoma 14.0.

Switches Tabs and the shown DB even across DB Servers.

This must be the single most scary and important bug?

anxiaowen commented 1 year ago

4.0.10 same

erikbaan commented 1 year ago

This is consistently happening to me. After inactivity for +- 15 minutes, the selected database is lost, and a random database (from the same connection) is in use. Has been this way for around a year, and is very frustrating. The workaround is to select another database, and switch back to the database that I originally wanted.

Maybe this is related to having multiple connection tabs open for weeks/months, until sequal ace has a crash (for whatever reason). I never close the app.

j-fulbright commented 11 months ago

Following this, as it is very dangerous and almost has caused some production issues

erikbaan commented 11 months ago

still happening with 4.0.13

SharkEsben commented 10 months ago

Frequently changes from dev to production database without visual change in dropdown after mac has been in sleep mode. This is pretty dangerous if you're not aware. Version 4.0.13 on Mac Sonoma 14.1

marcustrp commented 10 months ago

Version 4.0.13, same problem here. Two windows, one with prod and one with dev. Ran a query in dev window which acted on prod tables! Have had app open while computer went to sleep, so might have to to with the reconnection-problem in #1594 .

xpader commented 10 months ago

This is a very troubling problem. You must switch to another database and then switch back to the original database to return to normal.

xpader commented 10 months ago

The problem is that it seems to be restoring to the last selected database.

funaward commented 8 months ago

the issue has been a long time. I had to keep using 4.0.5. this is dangerous when you work on staging and prod db at the same time.

D-mawl commented 7 months ago

same problem ace: 4.0.14 mac: m2 14.4.1

daverogers commented 7 months ago

the issue has been a long time. I had to keep using 4.0.5. this is dangerous when you work on staging and prod db at the same time.

until this is fixed, you should run these environments in separate windows to keep them isolated. as a rule i always run my prod write account in a separate window and only keep it open so long as i'm actively using it to prevent mindlessly running a dangerous query. when you keep it in a tab, grouped with all your dev/staging tabs, it's like storing a live grenade in a box with avocados 😅 eventually you're going to cut into wrong one by accident lol. there are exceptions, of course, like if you always keep a certain tab order and know which one is prod then maybe that works fine for you.

funaward commented 7 months ago

the issue has been a long time. I had to keep using 4.0.5. this is dangerous when you work on staging and prod db at the same time.

until this is fixed, you should run these environments in separate windows to keep them isolated. as a rule i always run my prod write account in a separate window and only keep it open so long as i'm actively using it to prevent mindlessly running a dangerous query. when you keep it in a tab, grouped with all your dev/staging tabs, it's like storing a live grenade in a box with avocados 😅 eventually you're going to cut into wrong one by accident lol. there are exceptions, of course, like if you always keep a certain tab order and know which one is prod then maybe that works fine for you.

Hi daverogers, thanks for your message. I have marked different environment labels with different color. so I know the query runs on which environment.

wolfswinkel commented 7 months ago

Hi daverogers, thanks for your message. I have marked different environment labels with different color. so I know the query runs on which environment.

It's not always that labels do work when you have multiple db's opened in diffrent tabs from the same server. Today was a bit lucky because I didn't refresh (switch to a diffrent db and go back to the one I needed) and started truncating some tables. The query ditched for some other reason and didn't finish or even start as far as I could tell but the first tab I had opened should have been db A, instead db B was active there which had to be active in tab 2.

But this needs to get fixed. For me it only seems to concur when I haven't been active for a while. So for example today I just started the day so the tabs and stuff were still active from the day before or even before that day because I had a day off. During the day this doesn't happen that much as far as my experience goes. And I'm not hibernating, or let the Mac sleep. It's always on in my case.

erikbaan commented 6 months ago

Still happening on a daily basis with 4.0.13. Every time after a few minutes of inactivity.

macjimbo commented 6 months ago

This happens to me frequently and on one occasion caused a massive issue in our live database, necessitating a roll back to the previous full backup and piecing together subsequent transactions from different sources.

After leaving Sequel Ace dormant for an unspecified period, it changes the current database internally but the 'select database' menu continues to show the expected database. Consequently queries are run on the incorrect database, with potentially catastrophic results.

In my disaster scenario, I exported my live database and then, the next day, imported that live database into my test database. But, in fact, the database imported into the live database, overwriting all of the current tables with stale data which was almost 24 hours old.

Lesson learned, I now use a different MySQL login which does not have permissions to write to the live database, and use that login for all test purposes. But this is still a critical bug which can have dreadful effects.

maharrington commented 4 months ago

Same happening on Version 4.0.17 / Build 20067.

I've just had a similar instance where I've ran an UPDATE query on (what I thought to be) "database1" - based on what I had selected in the UI, however, it ran instead on "database2".

Refreshing the database tables showed after the fact that it had been ran on the other (incorrect) database, and is now being treated as a Major Incident in our business.

Given that this bug has been open for nearly a year, people regularly seem to have issues across different versions and could be a cause of business failure, do we have any expectation as to when this will be fixed?

jlawrence-yellostudio commented 2 months ago

I'm confused, are these not the same issues? These were apparently fixed in 4.0.15

https://github.com/Sequel-Ace/Sequel-Ace/issues/1056 https://github.com/Sequel-Ace/Sequel-Ace/issues/1797

@Jason-Morcos @Kaspik

Jason-Morcos commented 2 months ago

I'm confused, are these not the same issues? These were apparently fixed in 4.0.15

https://github.com/Sequel-Ace/Sequel-Ace/issues/1056

https://github.com/Sequel-Ace/Sequel-Ace/issues/1797

@Jason-Morcos @Kaspik

No - those were a different issue where adding a new tab would cause an issue. This issue is unrelated to tabbing and has not been fixed due to the difficulty to reproduce and test.

generalbretch commented 2 months ago

I would just like to back up the fact that this is not fixed. The major problem I see seems to happen after locking my mac for a period and then unlocking. If I then select a table this will nearly always result in a 'No database selected' popup, which will appear a further 10 or so times after dismissing it. Either that or I will see a 'table x not found in database y' message even though database y is not the one selected in the dropdown.

paolomartini commented 1 month ago

Just wanted to add my observation that this is not fixed (version 4.1.4, MacOs 15) and a major problem with the potential for very disturbing consequences. We have experienced this multiple times (and not just recently, but over a number of years), fortunately without disastrous consequences, as we have been able to catch the errors in staging or on review before delivering production to clients, but it is a disaster waiting to happen. I do understand that it is difficult to reproduce reliably, but it is possibly the bug with the highest risk of catastrophic consequences currently open for Sequel Ace.

Jason-Morcos commented 1 month ago

Sequel Ace is open source - we'd gladly review and accept a bug fix from the community that addresses this issue :)

paolomartini commented 1 month ago

Sequel Ace is open source - we'd gladly review and accept a bug fix from the community that addresses this issue :)

I hear you! My company is a 501(c)3 that also produces open source software, so I understand the limits. I wish I had the expertise to help, but this is beyond my abilities, or anyone I work with. I am worried that when a major mishap happens to us because of this bug (and it's been close multiple times recently) we'll be forced to stop using Sequel, and that would be a shame, because we love the app and very much appreciate the work you do to keep it going. So many thanks to everyone who contributes to this great software and I hope someone solves this issue.