Bug report #7797
QGIS becomes unresponsive while listing Oracle tables
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Jürgen Fischer | ||
| Category: | Data Provider/Oracle | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | worksforme |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 16689 |
Description
Using build 1959182 on windows 7 64 bit.
When connecting to our database (Oracle 10g), the system lists all of the tables. I suspect its doing some sort of scan of each table (this is without any of the checkboxes ticked).
If I close the "Oracle" dialog when it is scanning a particularly large table (i.e., 20 million rows), the dialog closes just fine.
However, QGIS itself remains locked up and unresponsive (won't even close) until the current table has been scanned (or whatever its up to). Which can be several minutes.
Related issues
History
#1
Updated by Per Engström almost 10 years ago
- Target version set to Future Release - High Priority
We have the same problem, I have tried Identify Feature on Oracle-objects using QGIS 2.4.0.1 and 2.6.0 and QGIS becomes unresponsive, i.e. stops working entirely while program window goes grey/white. Have to force quit and restart QGIS. My boss asks for this functionality and I don't know what to tell him... I work at Ludvika Kommun (municipally) in Sweden.
My boss has Windows 7 32-bit SP1 - QGIS Standalone Installer 32-bit
I have Windows 7 64-bit SP1 - OSGeo4W Network installer 64-bit
Database Oracle spatial 11g
Identify Feature works as inteded on shp-objects, info pops up in left margin instantly.
Identify Feature crashes QGIS on Oracle-objects (time out endless loop - requires force quit). Does Identify Feature call Oracle-db without login password?
This has not been fixed for 18 months, assign bug to another developer?
Best regards
#2
Updated by Giovanni Manghi almost 10 years ago
This has not been fixed for 18 months, assign bug to another developer?
consider support the bug fix?
#3
Updated by Jürgen Fischer almost 10 years ago
Giovanni Manghi wrote:
This has not been fixed for 18 months, assign bug to another developer?
consider support the bug fix?
It's a different issue - which a separate ticket #11722 was filed about it.
This ticket however is about the slow detection of available tables on large databases - this was to some extent addressed in 5b72daa434
#4
Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#5
Updated by Jürgen Fischer over 7 years ago
- Resolution set to worksforme
- Description updated (diff)
- Status changed from Open to Closed
Results of the scan are meanwhile cached.