On Dec 20, 4:49 am, [EMAIL PROTECTED] (Octavian Rasnita) wrote:
> From: "Chas. Owens" <[EMAIL PROTECTED]>
>
>
>
>
>
> > On Dec 20, 2007 4:58 AM, Octavian Rasnita <[EMAIL PROTECTED]> wrote:
> >> From: "Chas. Owens" <[EMAIL PROTECTED]>
>
> >> > On Dec 19, 2007 5:59 PM, Octavian Rasnita <[EMAIL PROTECTED]> wrote:
> >> > snip
> >> >> Sorry. No idea. I didn't wrote that C# program because I don't know C#
> >> >> well
> >> >> enough. That's why I was interested in a perl solution, but
> >> >> unfortunately
> >> >> it
> >> >> is not possible in perl.
> >> > snip
>
> >> > It is possible.  The person who wrote the C# library probably either
> >> > bought the $2,000 license for SEE* or rolled his or her own version of
> >> > it.  You can buy the license or roll your own version of SEE for Perl
> >> > as well.  It is quite possible, but, since you can't redistribute the
> >> > source code to SEE, there won't be CPAN module for it.  Frankly, not
> >> > being able to see the source code to System.Data.SQLite.DLL and its
> >> > unknown provenence (how can you trust someone you don't know) would
> >> > cause me to worry about its level security (did he or she put in a
> >> > back door?, did he or she make an error compiling it?, etc.).
>
> >> > * SQLite Encryption Extension
>
> >> Yes you are right. That dll might have a backdoor or some bugs in it, as
> >> well as any other Windows program that doesn't offer the source code.
> >> However, a C# programmer would be able to use an encrypted SQLite
> >> database
> >> very easy with it, while a perl programmer would need to create its own
> >> way
> >> of encrypting the database, and this might not be very easy.
>
> > Actually it is very easy: buy SEE, download DBD::SQLite, swap the SEE
> > code with the version of SQLite DBD::SQLite uses, do the Perl make
> > dance*.
>
> It would be still easier to use that dll than to buy a $2000 program... I
> guess. :-)
>
> Octavian- Hide quoted text -
>
> - Show quoted text -

Thanks you guys for your feedback.

I found out this morning that my previous SQLite database is still
being kept by Windows Vista in its Virtual Store and that's the one
that my application was trying to open which of course will have
conflict with the encrypted version of System.Data.SQLite.DLL. It was
not Vista after all or the new DLL that caused the issue, my bad! I
deleted the old database file so that my application can create a new
encrypted one and it works fine!

Merry Christmas to everyone!


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/


Reply via email to