I have a couple of threads and I'm using SQLite for storage. When I'm trying to access the database I'm getting SQLITE_BUSY error.
Is there a way how to fix this problem other than trying at each request ?
You are most likely running in serialized mode. But ... you're probably looking to run in multi-threaded mode instead. Note that you will need a separate database connection in each thread if you go that route.
Here is the link to the documentation goodness: http://www.sqlite.org/threadsafe.html
Ignore my last answer.
You can use the sqlite3_errmsg function to get the error message as string and print it using NSLog or other ways as soon as error occurs to find the more appropriate and proper reason.
http://www.sqlite.org/c3ref/errcode.html
You probably seem to be running in to serialization issue; I am not sure where.
Related
I suppose that this is more of a curiosity as opposed to an actual issue, but I thought I'd ask about it anyway. There are times when an uncaught error occurs in a server-side NetSuite script using SuiteScript 2.0/2.1 (2.x), but instead of seeing a "SYSTEM" scripting log entry, there's nothing. It gives the appearance of a script just stopping for no reason. Now, I know this can easily be avoided by wrapping everything within a try-catch block, but that's not what I'm trying to discuss here.
Does anyone have any insight into why a script would just stop without any SYSTEM error logging? It's just something I find interesting given that with the 1.0 API uncaught errors would always get logged. And it's not a guarantee that an uncaught error won't be logged as a SYSTEM log. It seems more common with map/reduce scripts, but unless memory is not serving correctly I believe that I have seen it happen with suitelets and user event scripts, too.
Just thought that I'd pose the question here to see if there was anyone who might know a little something about it.
This is actually covered in the system help for Map/Reduce scripts. They do fail silently. I've not seen this in any other script type.
When I try to disable a scheduled query in BigQuery web interface, I get this error:
Error updating disabled property. Please try again later.
I think that previously I made this kind of updates without problems... The "solution" I found is to remove the scheduled query, but in fact, I don't want to lose the query. Is this a new bug of this functionality or am I missing something?
I am building up a webapp with offline functionality. I am using combination of webcache and pouchDB to achieve it.
Currently I am testing recovery mechanisms against DB corruption. My premise is that since pouchDB is running in client, it is exposed to anyone who by mistake or on purpose can corrupt the DB. Also maybe in case of bugs or similar, DB could get corrupted. Then, if DB gets corrupted, unless it gets detected and clean by webapp, this will never work correctly.
Test is quite simple:
- Create PouchDB:
var dbOptions = {
auto_compaction : false,
cache : false
};
var db = new PouchDB('myDB',dbOptions);
With Developer Tools delete part of the database.
On loading the application it tries to read all documents:
db.allDocs({include_docs : true}, function(_err,_response){
(certain code here)
}
It is at this point when "Uncaught TypeError: Cannot set property '_rev' of undefined " is thrown. I tried to catch exception and using provided promise by pouchDB but none did work.
Did any of you fellows have similar problem? How did you solve it?
EDIT:
When PouchDB returns 500 Internal error, how is the application supposed to recover from it? I tried to destroy the database
db.destroy(function(err,info){console.log(err||info);}
but it does not work. It returns 500 Internal error as well.
It indeed sounds like your database got corrupted. Sorry about that; we try to write bulletproof code, but since we're working against the WebSQL/IndexedDB APIs, there's always the possibility that something goes wrong at that interface, the browser crashes, lightning strikes your computer, etc.
500 errors indicate an internal PouchDB error, so you're not supposed to recover from them. Probably the best way to protect against corruption like that is just to set up continual sync with a CouchDB server (kind of the point of PouchDB anyway). CouchDB is a full database implemented from top to bottom and is very robust – since it uses append-only database files, your database can never get corrupted. So if you use continuous sync, you can always delete the PouchDB database and recover from CouchDB.
That being said, if you could let us know which version of PouchDB you're running, which browser you saw this on, or even a code snippet to reproduce, that would be really helpful. If you're using Firefox, you can also send us the storage files themselves for IDB by following the instructions here to find the Profile folder and then sending us the contents of the storage/persistent/<my_site>/idb folder. Thanks!
I got this error while adding a new schema to my RxDB database. It turned out I included the primary key and wrong property names into encrypted fields. I removed the primary key and put proper names and it worked fine after that.
I'm trying to amend our content management system so it'll handle SQL database failures more gracefully. It's a bunch of ASMX pages, and a Helpers.vb file in which I've written a SQL connection tester function.
Each of the ASMX pages call the same function.
I need to create a variable I can check that's persistent and performant, otherwise I'm going to have fall back on something disasterously slow like reading a text file every time I set up a sql connection string.
I've tried using application caching, but either it doesn't work in the context of my helpers.vb file, or I've made a mess of the syntax. One problem that's already stymied some of the approaches I've found via google - I can't use 'Import System.Web.Caching' - IntelliSense doesn't show the 'Caching' part.
Has anyone got any example code that might get me up and running? Or an alternative approach?
#Mike,
Many thanks, now I'm using HttpRuntime.Cache correctly... it works!
Thanks everyone for taking the time to post :)
Background:
I'm working with a program coded in C++ which uses ODBC on SQL Native Client to establish connections to interact with a SQL Server 2000 database.
Problem:
My connections are abstracted into an object which opens a connection when the object is instantiated and closes the connection when the object is destroyed. I can see that the objects are being destroyed: their destructor are firing and inside of these destructors, SQLDisconnect( ConnHandle ) is being called, followed by SQLFreeHandle( SQL_HANDLE_DBC, ConnHandle ); However, watching the connection count using sp_Who2 or the Performance Monitor in SQL shows the connection count increasing without relent, despite these connections being destroyed.
This hasn't proven problematic until executing a chain of functions that runs long enough to create several thousand of these objects and as such, several thousands of connections.
Question:
Has anyone seen anything like this before? What might be causing this? My initial google searches haven't proven very fruitful!
EDIT:
I have verified that SQLDisconnect is returning without error.
Connection pooling is off. In fact, when I attempt to enabling it using SQLSetEnvAttr, my application crashes when the 2nd call to SQLDriverConnect is made.
Check that you are not using connection pooling. If it is turned on, it will cache opened connections for some (configurable) time.
If you are not using connection pooling, then you must check return value of the SQLDisconnect(). You may have some transaction executing or rollbacking that wont let SQL Disconnect() release your connection.
You have more details on how to check for SQLDisconnect errors at MSDN.
I believe I have seen the same issue in an application that uses MFC and ODBC, rather than the SQL native client API directly. Occaisonally my application hangs on shutdown, the stack trace is:
sqlncli!CCriticalSectionNT::Enter
sqlncli!SQLFreeStmt
sqlncli!SQLFreeConnect
sqlncli!SQLFreeHandle
odbc32!UnloadDriver
odbc32!FreeDbc
odbc32!DestroyIDbc
odbc32!FreeIdbc
odbc32!SQLFreeConnect
mfc42!CDatabase::Close
mfc42!CDatabase::Free
mfc42!CDatabase::~CDatabase
Try as I might, I cannot see anything that might cause such a hang. I'd be grateful if anyone can suggest a solution. It seems others have seen similar issues online, but to date I haven't found any solution.
sqlncli!CCriticalSectionNT::Enter
sqlncli!SQLFreeStmt
sqlncli!SQLFreeConnect
sqlncli!SQLFreeHandle
odbc32!UnloadDriver
odbc32!FreeDbc
odbc32!DestroyIDbc
odbc32!FreeIdbc
odbc32!SQLFreeConnect
mfc42!CDatabase::Close
mfc42!CDatabase::Free
mfc42!CDatabase::~CDatabase
From your stacktrace not having a bottom, can we assume that the CDatabase is a global variable?
Possibly in a dll?
We found your exact symptoms if attempting disconnect from SQL Server from within the destructor of a global variable.
Using the MDAC ODBC drivers works successully.
Moving the code out of the destructor works sucessfully.
It seems something to do with sql native client not liking being called from inside a DllMain.