I am using ZeosDB component to access sqlite database. It works fine on an unencrypted db.
On a encrypted db i receive : file is encrypted or not a database. Eaven if I set the password.
Is the DLL file I use wrong ? I use the last dll from the official page.It does not support encryption by default ?
There are several encryption schemes on SQLite3.
Among them, you have:
The official not free encryption library from SQLite3 authors, named SQLite Encryption Extension (SEE): just pay and use the dll, and modify the initialization to set the database key;
Open Source SQLCipher;
WXSQlite3 wrapper;
For Delphi, our Open Source static-linked version included in our mORMot (with a custom encryption) - static linking allow you not to use an external sqlite3.dll so it will help making your deployment and support easier - it features easy switch to MS SQL, Oracle or OleDB/ODBC with the same source code from Delphi 5 up to XE3 and has great speed;
See the link above.
ZeosDB SQLite3 level handle none of them.
The SQlite3 API driver (unit ZPlainSqLiteDriver) does not contain the cyphering. So you will have to change it. Or switch to another wrapper which support encryption APIs.
Recently I had the same problem (using UniDac). The official DLLs do not support encryption. There are a couple of libraries that include encryption, but they are not interchangeable. I.e. DB encryped with one SQLite DLL cannot be decrypted with the other distribution. I think your case is the same.
My solution was:
Downloaded the ...static bunde... package (x86, x64) for .NET - this supports encryption (windows DPAPI I think)
Renamed System.Data.SQLite.dll to SQLite3.dll -> this DLL is native DLL and supports enc/dec
In the folder of my DBMS I replaced SQLite DLL with the extracted above
This way DBMS encrypts using the new DLL, and your program can decrypt it using the same version of the DLL.
You can also take a look at:
SQLite with encryption/password protection
How to compile wxsqlite3 and sqlite to get encryption support
Notes:
Also make sure you copy SQLite3.dll to your program directory. Many other products use SQLite and are in the %PATH% so there's no guarantee the "right" SQLite3.dll will be loaded by your executable. Interesting solution can be found here;
Consult the license to see if you can use .NET's version for free, because of this.
Related
Is Delphi XE5 TZipFile able to handle encrypted/password protected zip files?
Or must users use third party software to handle this?
Any help would be appreciated.
Looking at the source code for System.Zip, I see no indication of anything that would allow working with encrypted Zip files. There is no provision for specifying a password for either zipping or extracting files or creating a Zip archive.
You could always include support for encrypted archives using Turbo Power Abbrevia, open-sourced several years ago by Turbo Power. It's been updated to support XE5, according to the SVN repository for the project at SourceForge. It's maintained quite well by the contributors to the project, comes with full source code, and is cross-platform (Windows, OS X, and Linux, at least - I don't see any indication of Android or iOS support).
I would like to know if there are any open source components available for Delphi XE-2 that can connect to postgreSQL other than using outdated techniques like ODBC.
For now just Win32 support is needed, but if Win64 and OS-X support is also available that would be a bonus.
I googled around a bit, but the only lib that's available (ZEOS) looks like it is no longer in active development.
There does seem to be a patch for Delphi XE2 but I could not get it to compile.
As of right now: No.
You either route through ADO -> ODBC, dbExpress -> ODBC (for XE2*, see below), hope to make Zeos work, or pay for one of the various commercial components (PostgresDAC, DevArt, or AnyDAC, to name a few).
While Delphi XE2 comes with an ODBC driver for dbExpress, it's only for the Enterprise SKU and higher -- it's not available in Pro. For XE2 Pro users and users of older versions of Delphi there's Open dbExpress. I've tried using it before, but always had trouble with it. It's been updated since I've last used it though, so maybe whatever problems I had (which may have been my own fault) aren't an issue anymore.
All this said, ODBC isn't really an outdated technology. On non-Windows systems it seems to be the preferred DB-agnostic API. That said, it seems that many environments prefer to implement their own connectivity (e.g. QT, GNOME) rather than relying on ODBC exclusively. However, for the PostgreSQL project itself, their default (and best supported) connectivity API is ODBC.
Update: In fact, Microsoft is making ODBC their premier connectivity API for SQL Server starting with SQL Server 2002 (codenamed Denali). See: Microsoft Aligning with ODBC and Microsoft is Aligning with ODBC for Native Relational Data Access. This is the last release that will support OLE DB, and Microsoft is encouraging developers to use ODBC.
Turns out you can get ZEOS to work on Delphi XE2 and as far as I've tested all DB functionality works.
Here are the steps to follow:
Use SVN* to download the Delphi XE2 archive for ZEOS at:
https://zeoslib.svn.sourceforge.net/svnroot/zeoslib/branches/testing
Put the zeos folder in the appropriate place, I'm assuming c:\borland
Do not open Delphi yet, but instead open
C:\borland\zeos\packages\delphi16\ZComponent.dpk in wordpad and remove the trailing {$IFDEF} (remember to keep the ; in place).
Open c:\borland\zeos\packages\delphi16\ZeosDbo.groupproj.
Choose build all
Open c:\borland\zeos\packages\delphi16\build in explorer, copy all .bpl files and copy those to c:\borland\delphixe2\bin
Component -> install packages -> [add...] and choose
c:\borland\delphixe2\bin\ZComponentDesign.bpl
as a SVN client I've downloaded SVN-tortoise from: http://tortoisesvn.net/downloads.html
Combined with both the SVN plug-ins for Firefox
I am wondering if we able to embed SQlite library into Delphi executable file and we may deploy our application as single .exe file without any SQlite dll file.
The embed is not keep the sqlite dll file into resource but link to Delphi executable file.
I have not tried this component out, but I plan to in the future
Delphi Inspiration - DISQLite3
There is also
Synopse OpenSource SQLite3 Framework
A Freeware version is available too
We have compiled SQLite3 with Borland's free command line tools C compiler and the resulting OBJ file we linked in Delphi with {$LINK 'OBJS\sqlite3.obj'}, and written the pascal wrappers for the functions we needed.
There was a problem resolving some standard C library functions when linking but we re-implemented them in Delphi.
I had the same problem and this is the solution I came up with. Maybe it can help you. Just include sqlite3 and you then have direct access to the dll functions. I used the same methods that have already be outlined:
http://simvector.com/download/delphi_sqlite3.zip
The DLL is just encoded in source form and the DLLLoader unit loads it at runtime. The end result is no extra DLL in your distro at the expense of it all being loaded into memory at once vs parts loaded on demand via the OS.
We needed it to work as normal, yet no extra dll in distro. So works for our needs.
Anydac SQLite driver has statically linked SQLite engine. It is commercial library, although. They has an article about anydac and sqlite.
Delphi can link .obj files, thereby if you have them available (or source code to compile them), you can link them into an executable. But you can't to that with the SQLLite dll.
IIRC DISQLite 3 does exactly that, check it.
You can download the SQLite open source and compile it into any environment that can compile vanilla C code. It's not especially hard.
I need to compress multiple files into a single archive using Delphi. I'd prefer to use freeware components or open-source components because I am very very cheap :-)
My primary requirements are:
Possible to encrypt the archive
Can create common archives that can be opened by anyone with a copy of WinZip
Does anyone have suggestions with components that they have used? Please feel free to suggest free as well as commercial components/libraries.
Perhaps DelphiZip is what you are looking for, it seems to support encryption, too, and is WinZip compatible. It is released under LGPL.
KaZip is an open-source ZIP archiver. Here is its description:
KAZIP is fast, simple ZIP archiver and
dearchiver which uses most popular ZIP
format.Inflate - Deflate zip
compression format (no encryption
support and no multidisk
support).KAZip is totaly based on
Delphi VCL - no DLL, ActiveX or other
external libraries.KAZip is totaly
stream oriented so you can deal with
data only in memory without creating
temporary files, etc. If you need to
add zip-unzip functionality to your
application,KAZIP is the right
solution. Additional ZipListView and
ZipTreeView components for easy
visualisation.Functionality:Zip-Unzip
using Inflate-DeflateBZip2 unzipping
trough usage of BZIP2 units from
Edison Mera Menndez.Functions:Adding
Files, Folders, Streams; Selecting,
Deselecting, Checking;Extracting to
files and streams;Delete and Rename
filesCreate, Delete and Rename
foldersTest, RepairMany new properties
and methods, improved speed.A very
complex Zip Browser demo application
is included
It is not compatible with Delphi 2009 yet, but with some minor changes in the source code, you can make it work in Delphi 2009 too. Actually, that's what I did.
Regards
I`m using madZip from madCollection
I'm surprised no-one has mentioned JclCompression yet - it's part of the well-known Jedi Code Library (JCL).
Here's a view of the unit itself : http://jcl.svn.sourceforge.net/viewvc/jcl/trunk/jcl/source/common/JclCompression.pas?view=markup
Note, it's compatible with 7-zip DLL version 4.64 - newer versions might not be backwards-compatible...
I recommend the $69 ZipForge from ComponentAce.
You could use 7zip (LZMA) bindings for Pascal (compatible with Delphi): http://www.birtles.org.uk/programming/
Another Delphi resource to look at would be InnoSetup. The source code is available and with a little work might give you an edge up on what your trying to do. There is an option to create self extracting zip archives which are compatible with WinZip,
My thoughts are not to use the program, but to use his source as a starting point since it is very heavily tested and extremely solid.
There are infozips zip32 and unzip32 dlls. They can be used from Delphi (even from Visual Basic), there are interface units/modules for both. The interface isn't as good as I would have liked it, but it works.
In the company that i work, we develop all the GUI in C#, but the application kernel is mainly developed in Delphi 5 (for historical reasons), with a lot of components made in COM+. Related to this very specific sort of application a I two questions:
Experienced guys in Delphi and/or COM, do you have any workrounds to work with the buggy TLB interface ?
Some of the bugs are: IDE crashing during edition of a large TLB, lost of methods IDs, TLB corruption, etc.
Here, we haven't found any good solution. Actually we tried do upgrade do the new 2007 version. But the new IDE TLB interface has the same bugs that we found before.
How do you control TLBs versions ? The TLB file is in a binary format and conflict resolutions are very hard to do. We tried to do it exporting the interfaces descriptions to IDL and commiting into CVS, but we didn't found any good way to generate TLBs from IDL using Delphi. Additionaly, the MIDL tool provided by Microsoft, didn't parse correctly the IDL files that we exported from delphi.
I think you should have a good look at Delphi 2009.
Delphi 2009 has changes to the COM support, including a text-based replacement for the binary TLB files.
You can read more on Chris Bensen's blog.
In the distant past (before I started working for CodeGear) I gave up on the odd Delphi-ized IDL language that the IDE presented, and wrote my own IDL and compiled it using MS midl. This largely worked; the only catch, IIRC, was making sure dispids (id attribute) were correct on automation interfaces (dispinterfaces) for property getters & setters - there was some invariant that tlibimp expected but midl didn't guarantee.
However, now that Delphi 2009 uses a safe subset of midl syntax, and includes a compiler for this midl in the box and integrated into the IDE, these problems should be a thing of the past.
We have also just installed Delphi 2009 and it does seem to have improved the support for Typelibraries. However I have worked with COM and type libraries for quite some time and here are my general gotchas that I have found over the years. I would agree its pretty buggy and is all the way up to Delphi 2006 (our version prior to using 2009).
Always have every file writeable before opening. This may sound obvious, but when working with source control sometimes we forget to do this and try to remove readonly flag after opening a file - Delphi cant deal with this. Ensure tlb is writable before opening.
If editing a standalone typelibrary you MUST have a project open. For some reason if you open a type library on its own it will not save. Create a blank project and then open your typelibrary. For some reason this allows the type library to be saved.
If your type library is used by an application or COM+ ensure that application is shut down or COM+ disabled before opening the type library. Any open apps will prevent the type library from being saved.
However I think your best solution is probably an upgrade. You get Unicode support too.
Using Delphi 2009 has greatly taken much of the pain out of huge TLB files, and conversion of our existing objects was painless, but our com objects don't use any third party libraries.
We will be migrating our gui applications over once the library vendors release supported versions.
Same experience with the TLB interface here: we simply stopped using it.
We work with several separate IDL files (hand-build) for different parts of our framework, making use of the #include construct to include them into the IDL of the actual application, then generate the single tlb using MIDL and tlibimp it. If the application has no IDL of it's own, pre-compiled version of the different framework TLB files are available.
Whenever the framework enters a new version, a script is run to re-generate the GUIDS on all necessary interfaces in the IDL files.
This has served us well for many years, and for us to move over the new Delphi 2009 IDL/TLB toolset will have to be not only integrated into the IDE, but also versatile when it comes to automated builds and whatnot. Can't wait to get my hands dirty with some experiments!