typo... sorry for the confusion, i'll be more careful in the future..
On 5/11/06, Edwin Hernán Barrios Núñez <[EMAIL PROTECTED]> wrote:
Hi ,
When i can download that sqlite version you take about, with
encryption extension.
I saw in your message that you use version 3.4.5 but on sqlte.org the
"=?ISO-8859-1?Q?Edwin_Hern=E1n_Barrios_N=FA=F1ez?=" <[EMAIL PROTECTED]> wrote:
> Hi ,
>
> When i can download that sqlite version you take about, with
> encryption extension.
> I saw in your message that you use version 3.4.5 but on sqlte.org the
> last one is 3.3.5.
>
> What is the diference
Hi ,
When i can download that sqlite version you take about, with
encryption extension.
I saw in your message that you use version 3.4.5 but on sqlte.org the
last one is 3.3.5.
What is the diference ? , where i can download encryption ( that it's
a need funcionality for sqlite )
Thanks !!!
I also agree with Ralf's proposal for sqlite3_column_affinity().
(Not that a vote on this topic will likely make a difference. ;-)
--- Ralf Junker <[EMAIL PROTECTED]> wrote:
> I second this.
>
> >I think real problem is that you have a function
> >called "column_type" which doesn't actually
--- Henning Friese <[EMAIL PROTECTED]> wrote:
> Joe Wilson wrote:
> >
> > :memory: is faster if you're not using transactions.
> >
>
> Hello Joe,
>
> thanks for your answer. I'm not using transactions,
I would recommend using file-based database transactions, as it is often
faster than
--- Pasquale Imbemba <[EMAIL PROTECTED]> wrote:
> I am using the sqlite wrapper by Christian Werner for Java on my Linux
> machine. I use eclipse and I have create da new project which contains
> the SQLite.jar stuff.
>
> Whenever I try to compile, I get the following error:
>
John Stanton wrote:
As you postulated, Sqlite's approach is indeed more rational.
Most SQL implementations use fixed-size records
so it makes more sense for them to enforce each
column's data type exactly - inserting a string
into a column which can only hold a single char
isn't very useful.
I endorse Jay's approach. In our web page software using Sqlite
everything is TEXT except for dates in Sqlite format. We use declared
types to indicate classes of text, such as decimal numbers and dates.
There are no radix conversion involved in data manipulation (apart from
dates), and we
As you postulated, Sqlite's approach is indeed more rational.
As for what you are doing, the way I did a similar thing for
compatibility was to make a function which looks at the declared type
and the actual type and makes the appropriate conversion if necessary to
match the destination
[EMAIL PROTECTED] wrote:
I continue to be bewildered by programmers'
fixation on datatypes. This has been a constant
theme for 6 years now. And in all that time, I
have never been able to figure out why so many
people think they need to know the "type" of a
"column".
The best theory I have
[EMAIL PROTECTED] schrieb:
Dennis Cote <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
I'm having trouble compiling the 3.4.5 version with encryption
extensions..
Question answered by private email.
Version 3.4.5...
I wonder if this is a typo or the mythical
D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> The best theory I have is that people who have
> always driven a stick shift must have difficulty
> driving a car with an automatic transmission
Well Yea!?! That clutch pedal almost threw me thru the windshield...
Hey what's this strap thing for???
Griggs, Donald wrote:
If your question still persists in the form of, "Is there a one-call method
in the API to write out any :memory: database to disk?", then I think the
answer is, "No, if ATTACH is too cumbersome, you would need to write your
own code as you see fit."
Henning,
Using a
On 5/10/06, sqlite <[EMAIL PROTECTED]> wrote:
We're C++ programmers and C++ is all about data types.
It's a statically typed language.
I dealt with it pretty simply in my application. It produces web pages
and web pages are text. Anything I retrieve is always retrieved as text.
No conversions
I second this.
>I think real problem is that you have a function
>called "column_type" which doesn't actually return
>the type of a column. This is counter-intutive.
A more telling name for sqlite3_column_type would probably be sqlite3_cell_type.
>If you could make it return the column
Hello Preston & Chrystie,
I can reproduce the error with SQLiteSpy.
I think it you should create a bug report ticket on www.sqlite.org, if you have
not already done so.
Regards,
Ralf
>Hi all,
>I recently upgraded my project from 3.2.2 to 3.3.5 (or if you look at
>my last post 3.4.5 ;) and
Ticket #1807 has been entered for this problem.
"Preston & Chrystie" <[EMAIL PROTECTED]> wrote:
> Hi all,
> I recently upgraded my project from 3.2.2 to 3.3.5 (or if you look at
> my last post 3.4.5 ;) and have found a situation where sqlite tries to
> access an invalid memory location in file
I don't know if this helps but when i was building a static version for
Windows
1. maked a static dll project and added all files but NOT precompiled
WIndows stufff..
If i added use precompiled windowsfile it never compiled..
// Anders
[EMAIL PROTECTED] skrev:
Hello,
I hope this isn't too
1. Open the required database.
2. Run the sqlquestion
select * from sqlite_master;
you get a declaration of table,namn and types.
// Anders
sqlite skrev:
Roger Binns wrote:
The types point still baffles me. If your code already
knows which column it is dealing with then surely the
code
Hello,
I hope this isn't too off-topic, really more a compiler question than
SQLITE.
I'm trying to compile Christian Werner's Sqlite JDBC driver under WinXP
using Platform SDK and VS2005. This process breaks with the follwing
error message:
Microsoft (R) Program Maintenance Utility Version
Roger Binns wrote:
The types point still baffles me. If your code already
knows which column it is dealing with then surely the
code should know what type to expect. (Eg if you are
dealing with a column named 'title' then you would
expect a string)
Let me explain what I was doing...
I was
Thursday, May 11, 2006, 09:36:17, Preston & Chrystie wrote:
> if your first statement after creating the database is:
> PRAGMA encoding = "UTF-16";
> then the error you get is slightly different:
sqlite>> ALTER TABLE test1 ADD straße VARCHAR(255);
> SQL error: malformed database schema - near
Joe Wilson wrote:
>
> :memory: is faster if you're not using transactions.
>
Hello Joe,
thanks for your answer. I'm not using transactions, I'm just doing a lot of
"INSERT INTO"s with a huge amount of data. It seems to be faster doing that
in a ":memory:"-db (I've already tried that). I just
if your first statement after creating the database is:
PRAGMA encoding = "UTF-16";
then the error you get is slightly different:
sqlite> ALTER TABLE test1 ADD straße VARCHAR(255);
SQL error: malformed database schema - near "(": syntax error
I was hoping that would fix it for you.. guess not,
Hi all,
I recently upgraded my project from 3.2.2 to 3.3.5 (or if you look at
my last post 3.4.5 ;) and have found a situation where sqlite tries to
access an invalid memory location in file vdbe.c line 3633 (pC==0). I
have confirmed that this query causes the command line utility
(pre-compiled
25 matches
Mail list logo
