SQLite Compat

Please give more details, a dump of your jaws_user settings.

BTW, sqlite is *supposed* to work but there's no warranty of it, not before we port all of our SQL queries.

Just replicated the error... the JawsSession? is looking for the id in the table users, however, in the table users there is no id :-S, this is an error during the create user step during install, I suspect it has something to do with the method $GLOBALSdb?->getBeforeId() A workaround would be entering your sqlite database and updating the user with id = 1 as it is the first user, but I just found that there are several different issues regarding how jaws manages the SQL queries that are not working with SQLite... I doubt they will get fixed for 0.6.0 as we need to check the queries throughfully and 0.6.0 is going out very soon. I think we should change this ticket to something like "SQLite compat" and target it to 0.7, but I'll let pabl0 have the last word.

So it goes

Jorge, please test again (svn up before) and report your results.

same problem, in general, auto_increment values are not being inserted, did a svn up just a few minutes ago. Saw MDB2 updates and other several updates (mostly images) but nothing seemed to change with sqlite.

We have fixed the auto increment problem (me and kad (jorge)) and now everything installs fine and blog posts and such get inserted just fine but we still have couple of problems with selecting from the database because sqlite is a bit stricter in cases of JOINs ... and there might be other edgy cases, jorge only tested it slightly but I think I fixed most of the bugs he encountered.

So the ball is rolling!

so far so good :-) I'll continue testing.

First issue: the function rand() doesn't exist in SQLite. This function is used by the Banner gadget in order to randomize the banner to display. A way around this should be to get an array from the database with several records and then randomize it via php code.

SQLite has something called random() I just have to make Lukas do the rand() func in the Funcation thing in MDB2 (or I will do it) to get this compatibility.

I finally got of my butt and updated MDB2 in trunk and made all the places I found use the random function instead of the hardcoded thing, now SQLite and PGSQL should work in that regards.

Let me know if there are more issues like this :)

Well, after some more testing it seems to be behaving properly. Two more issues though:

• DROP TABLE
  Error: Failed to load processor foo

  No macro or processor named 'foo' found

  seems to fail. Well, actually, it just does nothing, doesn't drop, but doesn't throw an error either. I saw there're some changes with oci8 driver regarding dropping, maybe sqlite needs something like that.

• Jms install/uninstall screen seems to fail under SQLite, haven't had the time to check the queries myself, but just want to keep it written somewhere :-)

I'm setting this as a blocker, should be ready for 0.7 :-)

Regards

Could you check yet again ? Since the 0.7 release is not too far away and all that.

I did... there's this little bug that I finally found, though I don't understand exactly what's happening. When doing the install, everything runs normal, and everything so far works ok. There's a problem with the Layout gadget though, the key /gadgets/Layout/enabled is not being inserted. The install process is crafted in such a way that this does not keep it from finishing, so you finish the install and that's the only key missing. Weird, huh? I checked the JawsRegistry::NewKey? method, put a bunch of debugging lines and finally I have an explanation. Check said method, it has a query like this one:

$sql = "SELECT COUNT(name) FROM [[{$this->_Table}]] WHERE name = {name}";

Which in turn translates to:

SELECT COUNT(name) FROM registry WHERE name = '/gadgets/Layout/enabled';

This raises a MDB2 error:

object(JawsError)#548 (3) {
  ["_Message"]=>
  string(225) "MDB2 Error: Array : _doQuery: [Error message: Could not execute statement]
[Last query: SELECT COUNT(name) FROM registry WHERE name = '/gadgets/Layout/enabled']
[Native code: 17]
[Native message: database schema has changed]
"
  ["_Code"]=>
  string(3) "SQL"
  ["_Level"]=>
  int(2)
}

I searched and it seems is a known bug in sqlite2(1), but strange thing is, it _always_ happens and it is the same key every time. I tested like 4 or 5 times in 2 different machines... Any suggestions on how we better approach this? Suggestions on the sqlite forums is to just re-issue the last statement... and some others claim this no longer happens in sqlite3... any thoughts?

Regards

1 http://marc.10east.com/?l=sqlite-users&m=110113412623982&w=2

I had same problems kad wrote but now I can install (maybe some mdb2 fixes Helgi commited), so kad, can you try again?

i test it and this error not see, so i close this ticket, but ticket #651 still open.