I would like to know if it's possible to read a .mdb file without the use of ODBC.
I need to write a Delphi application that reads 2 columns from a mdb file and writes those columns in a postgreSQL database.
Is there a trick, Delphi component or method that I can use that does not depend on ODBC.
(For some reason ODBC on my devel-laptop is broken).
If need be I can also use Delphi 2007, and I even have a version of Delphi 1,2 and 3 somewhere as well.
You can use ADODB. It is part of Delphi 2007, at least. It does not depend on ODBC or BDE: it uses OleDB/ADO instead.
long long ago, there was Data Access Objects DAO, but it appears that these are deprecated (all the way at the bottom). Still, with a bit of luck you could still find documentation for it and use it.
Related
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
Connecting to ADO is hard from installation in Delphi, so I decided to use VBscript, which I have never used before. VBscript has little support in Delphi, so how do I run a Windows script editor to get support and carry it over to Delphi? I do not understand the statements in VB script very well yet
My Delphi TTable is connecting to
the ADO
I need to connect to a
Microsoft DB file in c:\program
files\common\my folder\my file
I need to disconnect the ADO to
relocate this file and place a new
copy in its place periodically.
I looked up the MSN web site and it's not that helpful.
I see scripts that could be useful for many things if I can get them working.
Can anyone help please?
Lex Dean
The best way is to use the native (and easy) ADO components in Delphi.
You will found a example of 'how to do', with source, here :
http://sourceforge.net/projects/axbase/
You do not connect to ADO. You connect to a DB through ADO. ADO is a technology to connect to different databases using a common API - the database native API is taken care of by ADO drivers.
You say you need to connect to a "Microsoft DB" file but do not specify what kind. ADO can connect directly to Access files, but if you use SQL Server you never connect to a file, you connect to the database server.
Delphi has a different set of components to connect through ADO. They are the TADOxxxx component. TTable is built upon the BDE, and can't use ADO. Use TADODataset or TADOTable.
Using VBScript from Delphi is possible, but would not solve your problem easily - you will have to pass ADO objects to and from Delphi and VBScript, and it requires a good knowledge of Delphi, Windows, COM and so on. If you need to use ADO, take the straight path.
I'm trying to generate _TLB import units for Outlook 2003, 2007 and 2010 (and also other OLE servers) analogous to the ones bundled with Delphi for Outlook 2000 and 2002. However, I couldn't get the type library importer to also generate the code for capturing events from the OLE servers that is found in the bundled units. The option to "Generate component wrappers" only creates wrappers for servers that are directly instantiatable but not for objects that are only returned via methods of other objects like TInspector, TExplorer, etc.
I could of course create the event handling code myself but that would be really tedious work.
Does anyone know if the importer contained with Delphi 2010 (tlibimp.exe) can be tweaked to generate that code? I really doubt that back in the day Borland created the existing Outlook2000.pas and OutlookXP.pas units manually...
Are there maybe any other tools around that can do this?
Good question! I never noticed that those components were not created (I only use Word_TLB). After playing a bit with tlibimp I found out that you need the -Yc+ flag. Probably all ignore flags are default on.
NB: this is on Delphi 7 with tlibimp.exe version 7.0.4.453
I'm looking for a light-weight database engine for Delphi 1 (don't ask, it's a long story). Delphi 1 is 16-bit. The engine should compile into the EXE. SQL would be nice, but not mandatory. Any info would be great. Thanks, Carl
A 16-bit version of Microsoft Jet should be easy to integrate even with older versions of BDE (ODBC driver).
Otherwise you can use .db files (dBase - xBase), BDE should be able to handle them directly.
How about sqlite?
Turbo Power Btree Filer ? IIRC TP's is open source and TP was 16-bit.
Maybe this or the other DBF tool has 16-bit options. However the one I used (TDBF) doesn't afaik.
A long time ago I used VB/ISAM with Delphi 1. It works well with Delphi 16bit even though it was originally made for VB. It is from Software Source. I think we were using v4.x.
why not check on Delphi Super Pages web site. They use to maintain a complete code and component collections for Delphi 1.
I don't know the current situation though ;)
If you want I have a VBX based DB engine called VSData.
I never used Delphi 1 so I don't know as to how good it was at handling VBX. I have used this db engine as at that time this was the only engine to support storing multimedia files!
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W