Wow, that suprises me, i just stepped of the _gettable() call to get me the
result using prepare and step.
So i finally could read the $NUL BLOB data.
I can't imagne what would be better since a forward only behaviour is the
best there is.
Besides it's side-effects of not being able to navigate back.
There are people like me they never heard about TCL, i don't know what it is
and also what schema's are.
It's an area i never visit since it's not familiar to me.
I can not imagne to do things like this not using your API.
I don't think i'm blind for other things but there siomply are programmers
used to use plain functions.
To make sure you understand, through PowerBASIC i'm able to connect to your
sqlite through api's.
The issue is that conversion from your api to a BASIC syntax is pretty hard.
Espec. if calls have pointers which are in fact only interesting for
including the lib into c but is irrellevant to dll users.
Don't get me wrong, it's not to annoy you, just want to show my perspective
and might even help to consider this for the future.
Like a major rewrite to standard calls and making use of not-so-c syntax
(pointers/casting or whatever removed, just an example)
(Again: it's not handy to show *sqlite in a param but simply have a byval
hstmt as long (but then in c syntax :) ) would be much better since it does
not tell unecessary info that *sqlite is actually a pointer to a structure
or similar, this might reach more end-users)
I usually keep in mind a 'dumb' VB should be able to access it.
If that works it usually works with anything.
Using wrappers is no option to me unless it's for dotnet (asp.net), i fell
dumb if i would use a wrapper lib.
Of course the PowerBASIC code being spread for sqlite gives me a headstart
to access the dll.
But the code is not my taste so i do it myself.
Is there any reason not to stick with prepare() and step()?
Works for me at this time.
:)
----- Original Message -----
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Tuesday, August 23, 2005 1:28 AM
Subject: Re: [sqlite] Why can i open a textfile?
On Tue, 2005-08-23 at 00:04 +0200, Edwin Knoppert wrote:
All i meant is that sqlite is created by a c programmer, like my
colleague
he seems to forget there are different languages but he doesn't care.
Actually, I'm a TCL programmer. I only resort to C code to write
new TCL extensions. I personally never use the SQLite C API except
when I am working on internals of the TCL bindings. I use SQLite
in my professional work a lot, but I always access it through the
TCL bindings. Even when I am working on SQLite itself, I almost
always access it through the TCL bindings. (All of the test
scripts are writtne in TCL.)
And this brings up an important point: I'm increasingly aware of
the fact that the C API to SQLite really wants to be wrapped. There
are a lot of loose ends that can cause complication and trouble if
you try to use the C API directly in your application. Things like
the infamous SQLITE_SCHEMA returns. And the notorious SQLITE_BUSY.
And then the recent conversation about how to tell if the file is
really a database or not. These kinds of things are best dealt with
once in a wrapper and then forgotten. You do not want to have to
be worrying about error return codes when you are trying to make
the next great klller app. Programmers need to save their brain
cycles to focus on the really hard problems, not on handling lots
of pesky return codes.
Most people who are using SQLite successfully have, I imagine,
either written their own wrappers around the core API (which
is not hard as I do provide you with a lot of helper routines
such as sqlite3_vmprintf and friends) or they are using an existing
wrapper written by someone else.
If you are not doing this - if you are trying to make low-level
SQLite API calls like sqlite3_prepare and sqlite3_step for each
bit of SQL you want to run, then let me suggest that you are using
the library incorrectly. That is way too much work. I expose
those calls because they provide you with a lot of control and
give wrapper writers the freedom to do lots of interesting things
with the database. If you are working on an application that just
needs access to data, sqlite3_prepare and sqlite3_step are way
too low level. Find a wrapper suitable for your needs and use it
instead. Or write your own wrapper if an appropriate one can't
be found. This will result in a program that is easier to write,
easier to maintain, has fewer bugs, and just works better.
--
D. Richard Hipp <[EMAIL PROTECTED]>
