Because we can no longer overwrite tables directly using drag
and drop (refs #16805), add some explicit actions which allow
dropping existing tables (after user confirmation, of course!)
- Use [] to correctly quote field names instead of ""
- Don't invalidate provider side limit when not required
Forward port of 8dec70c, because I'm only human and forgot
Sets whether the connection should skip all handling of records with
invalid geometry, which are slow and costly.
This speeds up the provider, however, if any invalid geometries
are present in a table then the result is unpredictable and may
include missing records. Only check this option if you are certain
that all geometries present in the database are valid, and any newly
added geometries or tables will also be valid!
Why would we want this? Well, SQL Server invalid geometry handling
is AWEFUL. A seriously lame, data mangling and corrupting
piece of s***. Use Postgres instead. But if you can't, then you
can at least choose to use your layers at full speed, if you
can take the responsibility that a SINGLE invalid geometry
hiding somewhere in the table will result in a whole bunch
of missing (valid) features.
SQL server is at fault here, not us. There's nothing we (or
GDAL, or MapServer, or GeoServer, or anyone else) can do
to fix this.
Suffice to say, this option is off by default, as we're better
to have a slow provider which actually shows all features.
Fixes#15752
Rant over
Do it also in case of datasets that have a single layer, in case they might
later be edited to have more layers
(except for a few drivers known to be always single layer)
These are thrown by 3rd party components (e.g. webkit) which we have no
control over, and have low value anyway
Better to keep the debug log cleaner so that real errors are noticed
All your uses of toUtf8().data() actually just need a const char*
So use constData() that is semantically more correct, and documented
to be faster.
From http://doc.qt.io/qt-5/qbytearray.html#data
"For read-only access, constData() is faster because it never
causes a deep copy to occur."
Found with Valgrind
```const char* c_str = qstr.toUtf8().data()``` is invalid
since the QByteArray returned by toUtf8() is destroyed at the
end of the expression, letting c_str point to freed memory
On the contrary ```foo(qstr.toUtf8().data())``` is valid since
the temporary object is destroyed only after foo invokation.
