David Nelson ([EMAIL PROTECTED]) wrote:
> Am now thinking there's something wrong with how sqlite gets
> compiled (using MS Vers 6 Visual Studio)
Switch off all optimisations when compiling.
I more often had problems with MSVC in the past.
Hans-Jürgen
___
Mark Wyszomierski ([EMAIL PROTECTED]) wrote:
> I'm trying to upgrade to the latest version of sqlite (3.5.1) for
> windows. Compiling the sqlite library is fine, but linking to it I
> always get one unresolved symbol:
> unresolved external symbol _TryEnterCriticalSection
If you are using MSV
[EMAIL PROTECTED] (Aldo Giove) wrote:
> I ran the same statements on a home-built 3.0.8 under windows,
> getting this error message on the SELECT statement:
> Assertion failed: pX->op==TK_EQ, file D:\svil\lib\sqlite\where.c,
> line 383
Same here with VC6 and gcc 3.3.1 (cygwin).
Function st
b.bum ([EMAIL PROTECTED]) wrote:
> SQLite3 produces smaller data files
thats true,
> and is faster, in general, than did SQLite2.
but this is not my experience. In my small applications (about 20
records) inserting and searching with SQLite 3.0 is slower than SQLite 2.8
(about 25%). Ther
Matt Sergeant ([EMAIL PROTECTED]) wrote:
> This is now the only thing holding back DBD::SQLite's port to
> sqlite3. I've got everything else working and it's all looking
> great. inserts are about the same speed as sqlite2, but selects
> have sped up about 30%.
That's not my experience. Inse
Julian Brierley ([EMAIL PROTECTED]) wrote:
> Hans-Juergen Taenzer wrote:
>> doing some tests with the new version, I have encountered a
>> problem:
>>
>> void testva(void)
>> {
>>char *s;
>>unsigned long ul1 = 0x7FFF;
>&
hello,
doing some tests with the new version, I have encountered a problem:
void testva(void)
{
char *s;
unsigned long ul1 = 0x7FFF;
unsigned long ul2 = 0x;
s = sqlite3_mprintf("%lu", ul1);
printf("ul1: %lx, %s\n", ul1, s);
s = sqlite3_mprintf("%lu", ul2);
D. Richard Hipp ([EMAIL PROTECTED]) wrote:
> George Ionescu wrote:
>> What would be your advice regarding compiling SQLite under
>> Windows:
>>
>> - wait until it's more MSVC 6.0 friendly or
>> - start using Visual C++ 2003 ?
>>
> I've made changes so that CVS HEAD should compile
Julian Brierley ([EMAIL PROTECTED]) wrote:
> Hans-Juergen Taenzer wrote:
>> Even with Visual C++ 2003 there are problems:
>> VC 13 now supports the 'long long' datatype, but it does not
>> support the '%lld' format specifier.
>>
>&g
Doug Currie ([EMAIL PROTECTED]) wrote:
>> The '%lld' is used by SQLite in non debugging code.
>> For example: vdbemem.c function sqlite3VdbeMemStringify()
> This is a libc/runtime issue that is common to both VC and gcc
> running on windows (i.e., mingw, but perhaps not cygwin).
With gcc ve
George Ionescu ([EMAIL PROTECTED]) wrote:
> What would be your advice regarding compiling SQLite under
> Windows:
> - wait until it's more MSVC 6.0 friendly or
> - start using Visual C++ 2003 ?
Even with Visual C++ 2003 there are problems:
VC 13 now supports the 'long long' datatype
hello,
after successfully building SQLite 3.0 with the latest CVS sources make
test failed. See attachment.
Is this a problem with TCL or SQLite?
gcc version 3.3.1 (cygming special)
tcl version 8.4.1
Second question: what's the reason for not doing the tests printf.2.x.x in
the testfile "printf
DJ Anubis ([EMAIL PROTECTED]) wrote:
> Le samedi 19 Juin 2004 09:28, Hans-Juergen Taenzer a écrit :
>> But for example in the interface file sqlite(3).h there is not
>> made use of this typedef (or INT64_TYPE defined in sqliteInt.h):
>>
>> long long int sqlite
Daniel K ([EMAIL PROTECTED]) wrote:
> Can you try the following experiment and post the
> results:
> CREATE TABLE tbl(a INTEGER PRIMARY KEY, b INTEGER);
> INSERT INTO tbl VALUES( -1, 1.12589990684e+15 );
> SELECT * FROM tbl;
> and see what happens. If you get the right value
> back (-1,
hello,
compiling SQLite 3.0.0 in an cygwin environment I am getting compiler
warnings:
../sqlite/src/util.c:1175: warning: integer constant is too large for
"long" typ
../sqlite/src/vdbe.c:3022: warning: integer constant is too large for "long" typ
../sqlite/src/vdbe.c:3029: warning: integer cons
DJ Anubis ([EMAIL PROTECTED]) wrote:
> Le vendredi 18 Juin 2004 22:20, Hans-Juergen Taenzer a écrit :
>> I don't think there would be problems with the new version 3.0 if
>> there wasn't the problem with the 'long long' datatype. Just
>> using
Hihn, Jason ([EMAIL PROTECTED]) wrote:
> I am not the one to answer this, but I do know the mains that
> KJSEmbed is going through at the moment. The whole delay is trying
> to get it to compile in MSVC, but they moved to mingw32, where
> it's much more standard. They've since been chugging a
D. Richard Hipp ([EMAIL PROTECTED]) wrote:
> Version 3.0.0 (alpha) of SQLite is now available on the
> website.
Will there be support for other compilers than GNUC?
For example the datatype "long long" is not supported by MSVC.
In the prior versions there were the typedef off_t, which was defi
D. Richard Hipp ([EMAIL PROTECTED]) wrote:
> Here are the options:
> (1) Extend the syntax of the COPY command to allow the user
> to specify the text representation of the file being
> imported.
I would prefer this option. In addition it should be possible to remo
[EMAIL PROTECTED] (Chang Yong Ngan) wrote:
> can sqlite be used under MSDOS?
> thanks
You can compile SQLite with DJGPP to an 32bit DOS programm. To run it,
there must be support for LFN (long file names) by the OS like Win32 or
OS/2.
Gruss
Hans-Jürgen
--
Hallo,
i want to Port an Linux/Windows Application (mailfilter) which is
usingSQLite as an backend to OS/2.
Does anyone know, whether there is a Port of Sqlite to OS/2?
The DOS32-Port of SQLite is not sufficient because of the missing lfn-
support.
Thanks
Hans-Juergen
Gruss
Hans-Jürgen
-
21 matches
Mail list logo
