I would like to propose this version of winCurrentTime() which generates the
same results as the current implementation but much simpler:
int winCurrentTime(sqlite3_vfs *pVfs, double *prNow) {
FILETIME ft;
ULARGE_INTEGER ft64;
#if SQLITE_OS_WINCE
SYSTEMTIME time;
GetSystemTime(&time);
/*
Shane Harrelson writes:
> I'd be worried that other 64 bit calculations are going wrong as well.
>
> Can you verify what type sqlite3_int64 is being set to in your environment?
>
> Also can you try the following (note the L suffix on the constants):
>
> static const sqlite3_int64 max32BitValue
Thank you, it works now!
Jay A. Kreibich-2 wrote:
>
> On Fri, Feb 26, 2010 at 07:21:08PM -0500, Igor Tandetnik scratched on the
> wall:
>> senglory wrote:
>
>> > insert into TB_GroupCalendar(CalendarName) VALUES('DEFAULT CALENDAR
>> > FOR ' + UserName) ;
>>
>> What does UserName refer to he
On Fri, Feb 26, 2010 at 07:21:08PM -0500, Igor Tandetnik scratched on the wall:
> senglory wrote:
> > insert into TB_GroupCalendar(CalendarName) VALUES('DEFAULT CALENDAR
> > FOR ' + UserName) ;
>
> What does UserName refer to here? If you want to use the value from the
> just-inserted row, tha
senglory wrote:
> tbl definition
>
> CREATE TABLE [TB_User] (
> [ObjectID] INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
> [UserName] VARCHAR(30) UNIQUE NOT NULL,
> [IsActive] bit DEFAULT '1' NULL
> );
>
>
> trigger definition:
>
> CREATE TRIGGER [ON_TBL_TB_USER_INSERT_ADD_DEFAULT_CALENDAR]
>
tbl definition
CREATE TABLE [TB_User] (
[ObjectID] INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
[UserName] VARCHAR(30) UNIQUE NOT NULL,
[IsActive] bit DEFAULT '1' NULL
);
trigger definition:
CREATE TRIGGER [ON_TBL_TB_USER_INSERT_ADD_DEFAULT_CALENDAR]
AFTER INSERT ON [TB_User]
FOR EACH ROW
>> > So is such behavior documented and can be used or should I still avoid
>> > keeping such "live" statements in db-shared enviroment?
>>
>> It's documented that sqlite3_finalize AND sqlite3_reset release all
>> locks acquired by the statement. So after resetting the statement you
>> can keep it
On 26 Feb 2010, at 9:25pm, Francisco Azevedo wrote:
> I started with a auxiliar table with same columns,
> then, before edition i clean auxiliar data and copy from original:
>
> delete from _table; insert into _table select * from table;
>
> now, user can edit table (inserts, deletes, updates)
Hi all,
I want to create a "publish/undo system" for some tables but i don't
know what is the best approach to do it.
Imagine i have a table with columns id (auto-inc), data (text) then i
want to edit table data (eg: create 2 new rows now, delete one tomorrow,
update 3 rows tomorow too) and then d
On Fri, Feb 26, 2010 at 1:49 AM, 4eanlss <4ean...@engineer.com> wrote:
>
> Shane,
>
> I apologize for my quick snap response.
> I have debugged the code and have identified what is happening.
> The calculation in my environment results in 0 (zero) for this:
> static const sqlite3_int64 max32BitVa
On Sat, Feb 20, 2010 at 10:09 PM, Simon wrote:
> I also can stop the process between any two calls to sqlite3_step, my issue
> is with the first one that (to me) does not seem interruptible.
>
> I just tried adding a call to CHECK_FOR_INTERRUPT just after "for(pc=p->pc;
> rc==SQLITE_OK; pc++){"
thanks for you reply.
in my case, it is a multi-client platform, but for one data connection, only
one process/client will change it.
Superway
Simon Slavin-3 wrote:
>
>
> On 26 Feb 2010, at 10:41am, Superway wrote:
>
>> I am porting sqlite to a platform, where the filesystem do not support
>
On 26 Feb 2010, at 10:41am, Superway wrote:
> I am porting sqlite to a platform, where the filesystem do not support
> lock/unlock mechanism.
> does it possible to work on this type platform? if so, how to do it?
Do you need the results of locking ? In other words, is there any change that
two
Hi.
I am porting sqlite to a platform, where the filesystem do not support
lock/unlock mechanism.
does it possible to work on this type platform? if so, how to do it?
thanks in advance
Superway
--
View this message in context:
http://old.nabble.com/port-sqlite-to-a-platform-without-lock-unloc
> "Instead of cancelling the transaction, the ROLLBACK TO command
> restarts the transaction again at the beginning. All intervening
> SAVEPOINTs are cancelled, however."
>
> Say we have the following events:
>
> begin
> insert
> update
> savepoint A
> update
> savepoint B
> insert
> delete
> savep
Forget the previous post as it's probably wrong. I was misinterpreting
the ROLLBACK TO discussion. In fact I was led to believe there were
two forms: "rollback to" and "rollback to ". This is not
the case.
But then, I still have hard time understanding this part:
"Instead of cancelling the
On Thu, Feb 25, 2010 at 6:53 PM, Pavel Ivanov wrote:
> > So is such behavior documented and can be used or should I still avoid
> > keeping such "live" statements in db-shared enviroment?
>
> It's documented that sqlite3_finalize AND sqlite3_reset release all
> locks acquired by the statement. So
The diagrams in the following pages of the documentation don't allow
for the "ROLLBACK TO" construct: lang_savepoint.html and
lang_transaction.html
lang_savepoint.html also contains a 'tranaction' typo.
___
sqlite-users mailing list
sqlite-users@sql
18 matches
Mail list logo
