On Mon, Aug 25, 2008 at 6:33 PM, Derek Developer
<[EMAIL PROTECTED]> wrote:
> Dennis thank you for taking the time to explain that. I have read the
> Architecture page and I think I have a better idea.
>
> Since this does seem to be a viable way to protect the data I would like to
> implement
Write a C test.c program that uses the desired type. Then do "gcc -E test.c
> test.txt".
This will expand/flatten all the macros. Open the test.txt file and look for
the type.
On Mon, Aug 25, 2008 at 5:30 PM, Brown, Daniel <[EMAIL PROTECTED]> wrote:
> Good afternoon list,
>
> I'm attempting to
>No, the index is stored in a separate Btree. The master table simply
>stores the page number of that btree's root page. With that information
>SQLite can read and decrypt the index's root page and begin a O(log N)
>search for the first matching record, reading in and decrypting more
>pages as
Igor Tandetnik wrote:
>
> Since I'm not entirely clear of the set of premises you refer to as
> "that", I'm not sure whether they happen to be the case or not. But
> since I know the conclusion you arrived at is false, I can only assume
> that one or more of those premises are incorrect,
Derek Developer
<[EMAIL PROTECTED]> wrote:
> appologies, "master database" should read "MASTER TABLE"
> This is where the index is stored I assume?
An index is an index. It's not stored in any table, "MASTER" or
otherwise.
> You suggested that each record would NOT be decrypted for a SELECT
>
Derek Developer wrote:
> appologies, "master database" should read "MASTER TABLE" This is
> where the index is stored I assume?
>
No, the index is stored in a separate Btree. The master table simply
stores the page number of that btree's root page. With that information
SQLite can read and
appologies, "master database" should read "MASTER TABLE"
This is where the index is stored I assume?
You suggested that each record would NOT be decrypted for a SELECT because the
INDEX would handle that work. Since the INDEX is proabably not a MAC hash of
the SS# then it would be accessible
Thanks for all the advice, I'll use void* pointers for SQLite internal
structures which was my plan B if I couldn't find a declaration to feed
the compiler to calm it.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brown, Daniel
Sent: Monday, August 25,
On Mon, 25 Aug 2008 12:26:18 -0700, you wrote:
>Interesting, I just tried that in my test application and Dennis's and I
>get access violations during the vacuum command execution when trying to
>resize the pages from 1k to 4k with my database or Dennis's test
>database.
I just used the command
Brown, Daniel <[EMAIL PROTECTED]> wrote:
> I'm attempting to wrap SQLite with Managed C++ and I'm getting some
> compiler warnings as the compiler/linker is have trouble finding the
> declaration of the structure 'sqlite3_stmt', I've tried looking for it
> manually but I can't find it either
It's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brown, Daniel wrote:
> I'm attempting to wrap SQLite with Managed C++ and I'm getting some
> compiler warnings as the compiler/linker is have trouble finding the
> declaration of the structure 'sqlite3_stmt', I've tried looking for it
> manually but I
On Mon, Aug 25, 2008 at 02:30:44PM -0700, Brown, Daniel wrote:
> I'm attempting to wrap SQLite with Managed C++ and I'm getting some
> compiler warnings as the compiler/linker is have trouble finding the
> declaration of the structure 'sqlite3_stmt', I've tried looking for it
> manually but I
Good afternoon list,
I'm attempting to wrap SQLite with Managed C++ and I'm getting some
compiler warnings as the compiler/linker is have trouble finding the
declaration of the structure 'sqlite3_stmt', I've tried looking for it
manually but I can't find it either all I can find is a typedef on
Brown, Daniel wrote:
> Interesting, I just tried that in my test application and Dennis's and I
> get access violations during the vacuum command execution when trying to
> resize the pages from 1k to 4k with my database or Dennis's test
> database.
>
Daniel,
I have found that sqlite works
Derek Developer
<[EMAIL PROTECTED]> wrote:
> So if the data is indexed prior to the encryption step, does SQLite
> manage that index internally as a Btree that s stored somewhere? Is
> it part of the MASTER database?
I'm not sure what you mean by "MASTER database" (as opposed to which
other
Thanks Igor,
So if the data is indexed prior to the encryption step, does SQLite manage
that index internally as a Btree that s stored somewhere? Is it part of the
MASTER database?
Obviously there would be a security issue if the index is accessible as per
this:
Derek,
I'm more "onlooker" than "expert" here, but I think the answers are:
1) Yes, when a full table scan is performed, the entire table data is
decrypted. (If you're using a LIMIT clause without an ORDER BY, then
perhaps only part is decrypted -- the point being that the same pages
are read
Derek Developer
<[EMAIL PROTECTED]> wrote:
> Thank you for your replys, but I am still not sure I understand how a
> Query is executed on (page) encrypted data wihout either indexing the
> data prior to encrption, creating a secondary hash column of the data
> or simply decrypting every page to
Thank you for your replys, but I am still not sure I understand how a Query is
executed on (page) encrypted data wihout either indexing the data prior to
encrption, creating a secondary hash column of the data or simply decrypting
every page to get at the underlying data?
Would greatly
Interesting, I just tried that in my test application and Dennis's and I
get access violations during the vacuum command execution when trying to
resize the pages from 1k to 4k with my database or Dennis's test
database.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
unsubscribe
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
On Sun, Aug 24, 2008 at 6:18 PM, Susan Ottwell <[EMAIL PROTECTED]>wrote:
> How would one insert rows randomly within a range of 1000 rows? I can
> easily enough do this in the script that calls the insert function,
> but it would be more efficient if I could use an sqlite function or
> feature to
Susan Ottwell wrote:
> How would one insert rows randomly within a range of 1000 rows? I can
> easily enough do this in the script that calls the insert function,
> but it would be more efficient if I could use an sqlite function or
> feature to do this.
>
I'm not sure if this is what you
Hi,
Can some one confirm the following for me? I checked the documentation,
but still want to confirm once again.
The cache size and page size can be configured per database connection.
Setting the cache/page size via PRAGMA in one connection will not affect
the sqlite library affecting other
>>Add FROM T1 for last tests.
Personal Oracle Database 10g Release 10.2.0.3.0
CREATE temp TABLE t1(a INTEGER, b INTEGER);
INSERT INTO t1 VALUES(1,2);
INSERT INTO t1 VALUES(9,8);
SELECT a AS b, b AS a FROM t1 ORDER BY a;
B A
--
25 matches
Mail list logo
