| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
(issue 1763).
|
| |
|
|
|
|
|
|
|
| |
Many issues with handling connections in MSSQL, have rearchitected to
ensure that connections are always opened and closed in a timely fashion
& disposed of cleanly, and removed unnecessary lock statements. SQL
Server performance seems to have improved considerably as a result,
and various timeout errors seem to have been fixed.
|
| |
|
|
|
|
|
|
|
| |
On an MSSQL-based Grid OpenSim installation, users could log in to the sim once,
then log off - after a short time before retrying users would be unable to log in,
and would see an empty alert box on the client with just a "close" button and no text.
Despite no users being logged into the sim, user server would report a higher number
of logins than logouts.
|
| | |
|
| |
|
|
| |
kerunix_Flan!
|
| | |
|
| | |
|
| |
|
|
| |
ASCIIEncoder in places we shouldn't.
|
| |
|
|
|
|
|
|
| |
settings as when an inventoryitems table is newly created
* Normalize logging titles in database code, though this doesn't yet cover invoking code
|
| |
|
|
| |
(this took a while to run).
|
| |
|
|
|
| |
:: Believe it or not, but INSERT/UPDATE is actually a better pattern than REPLACE, since, with INSERT/UPDATE you can catch erroneous UPDATES to non-INSERTed items as well as catch erroneous re-INSERTS. in 95% of the cases, you SHOULD have a clear INSERT context, and a clear and separate UPDATE context. If you think your case falls within the 5%, maybe you should re-evaluate your code. ::
|
| | |
|
| |
|
