Thanks, I'll pick it up.
The first thing to ask yourself here is whether or not it makes sense to
use a database. Certainly that makes sense if you need concurrent read
and write access, but if you only need to write from one source at a
time an XML file sounds more like what you need. It
JD Smith wrote:
An old associate of mine wrote a quick and dirty C++ SQLite wrapper when he
started using SQLite. He passed me a copy of it to test out a few years ago
and I've been using it and SQLite when I need database access.
Somehow, up until now, I never ran across this
An old associate of mine wrote a quick and dirty C++ SQLite wrapper when he
started using SQLite. He passed me a copy of it to test out a few years ago
and I've been using it and SQLite when I need database access.
Somehow, up until now, I never ran across this particular problem... I
michael munson wrote:
> Greetings,
> I'm a bit new to SQL and SQLite so pardon me if I ask silly questions but I
> have run into a bit of a wall while attempting to design a database for a C++
> program I am attempting to write.
>
> The needs of the database are to: represent an object oriented
Hello michael,
If I was doing that, I'd have another table of nothing but "properties".
Each property would have an integer that represents which object the
property belongs to. In that way, there's no limit to the number of
properties you can assign to an object. In the case of your
parent/child
Greetings,
I'm a bit new to SQL and SQLite so pardon me if I ask silly questions but I
have run into a bit of a wall while attempting to design a database for a C++
program I am attempting to write.
The needs of the database are to: represent an object oriented hierarchy of any
number of
Hello drh,
Your mail server was unhappy about the attachments.
C
Saturday, January 14, 2006, 9:51:46 AM, you wrote:
dhc> Teg <[EMAIL PROTECTED]> wrote:
>>
>> To me the proper solution would be to avoid using TLS in the first
>> place since, you (sqlite) neither create nor destroy the thread.
Hello drh,
Like Igor, I like the critical section, the problem is that pesky
"Try" function which doesn't exist in older windows versions. The
mutex though lets you try by attempting the lock with a timeout. I'm a
little leery of the timeout in the "Try", I think it smells a bit of a
race
--- Martin O'Leary <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> I have a table like the following:
>
> CREATE TABLE user_actions (
> uid INTEGER NOT NULL,
> actionid INTEGER NOT NULL,
> time INTEGER NOT NULL,
> status INTEGER NOT NULL,
> PRIMARY KEY (uid, actionid, time,
I am using SQLite 2.8.14. I realize I should upgrade, but I using it
with PHP and would need to upgrade to PDO first, which be a lot more
work than the triggers I need help with :).
--
--
Randy Syring
RCS Computers
502-896-4143
www.rcs-comp.com
"Whether,
Teg <[EMAIL PROTECTED]> wrote:
>
> To me the proper solution would be to avoid using TLS in the first
> place since, you (sqlite) neither create nor destroy the thread.
>
I'm trying to move in this direction - to eliminate the need
for TLS entirely. But in order to do so I am going to need
Doug Nebeker <[EMAIL PROTECTED]>
wrote:
I have a small number of read and writer threads. A few months ago I
had some deadlock issues and one simple solution was to run all
transactions as exclusive (ie BEGIN EXCLUSIVE). That works
perfectly--no hint of deadlock. But now that I've been using
Miha Vrhovnik wrote:
using sqlite 3.2.8.
CREATE TABLE movies (id INTEGER PRIMARY KEY, catalogIDNumeric
INTEGER);
INSERT INTO movies (catalogIDNumeric) VALUES(1);
INSERT INTO movies (catalogIDNumeric) VALUES(2);
INSERT INTO movies (catalogIDNumeric) VALUES(3);
INSERT INTO movies
using sqlite 3.2.8.
CREATE TABLE movies (id INTEGER PRIMARY KEY, catalogIDNumeric INTEGER);
INSERT INTO movies (catalogIDNumeric) VALUES(1);
INSERT INTO movies (catalogIDNumeric) VALUES(2);
INSERT INTO movies (catalogIDNumeric) VALUES(3);
INSERT INTO movies (catalogIDNumeric) VALUES(5);
INSERT
14 matches
Mail list logo
