odbc stats.c: Stick fully with the designated database.#588
Conversation
|
I suppose the reason for this change is to avoid the need to create a database with the required permissions associated. Or is there any other reasons? That should be stated in the commit message. Also worth saying that using default database is not limiting the effectiveness of the test (or at least it seems so looking at the code). |
07f3419 to
6996eec
Compare
|
Done:
On a somewhat related note (which of course deserves its own PR), it would be helpful if tests used temporary database objects to the extent possible; using nominally permanent ones is mostly no problem but can result in race conditions when running multiple tests at the same time. |
|
Unfortunately there's a reason why using a different database. Queries we must send internally are different if the database is different from the current. To fix the permission issue I suppose we can assume the presence of both |
The precise database name has no bearing on this test's effectiveness. However, the test cases that explicitly specified a catalog (in ODBC parlance) to TestTable historically insisted on using freetds_test, and this test's only provision for lacking such a database was attempting to create it itself despite not necessarily having sufficient privileges. Bypass potential optimizations by formally changing to master before explicitly supplying the specified database name, with the help of a set_dbname copied from connect2.c. Signed-off-by: Aaron M. Ucko <ucko@ncbi.nlm.nih.gov>
6996eec to
f4d23fa
Compare
|
Good point, though
|
|
Wonderful! Testing, did some changes (appveyor, userguide). |
|
Merged, see 37e6856 |
|
No problem. Thanks for pointing me in the right general direction and adding final touches! |
Continue to run against it when explicitly specifying a catalog (in ODBC parlance), rather than attempting to create(!) (if absent) and use freetds_test.
Split from #555.