Rad Studio Delphi XE and PostgreSQL - delphi

I'm starting a new project, and this must be done in Delphi, so we get Rad Studio XE (not XE2). I have never wrote code in Delphi, I'm a C#.NET-MSSQL experienced programmer, that's why this project is exciting.
For DB, we cannot afford MSSQL, but the Express Edition is not leaved. So, we choose PostgreSQL, we have very excellent references about it. And I found it quite interesting.
But here comes the problem, the provider for the connection. I began research for this problem, and I found many options, there are some products with commercial license (AnyDac, and others). But we can't afford them. Then I found Zeoslib. Maybe it is what we're looking for, however, I can't find it and install it for XE. In the sourceforge portal, the latest version (it's an alpha), only works until Delphi14 (XE is Delphi15).
I've read too, that it requires to be compiled for the install (I need a step by step for dummies manual :D). But, this makes me doubt. How it will be deployed on the client. Is it a dll?
The project is a desktop application which connects to a server (DBMS), using CRUD statements, maybe some sprocs, ans that's all. Of course there will be more than 1 client. Just reading, updating deleting, etc..., but not at the same time, so traffic, concurrency is not a big problem.
In NET, I use the sqlclient namespace create connections, commands and that's all. I've found in Delphi the TSQL, TADO, and other objects like that. So it will be not hard at all.
So we're planning to use MSSQL Express instead.
But before that:
Is there another option to connect my RAD XE app with Postgres?
If someone knows how to enable zeoslib, can u tell me?
How is zeoslib distributed with my app in many PC's?
or
Is MSSQL Express a good choice for this project? (It's not big after all)
After reading, MySQL uses zeoslib too, and of course, the commercial providers. That's why we discarded it, among other reasons.

A component library, like ZeosLib or AnyDAC, requires to compile it into binary packages (BPL) to install into RAD Studio IDE. A libray itself may be either statically linked into EXE (nothing from library to deploy), or EXE may be built with run-time packages (you need to deploy library run-time packages). Additionally you will need to deploy libpq.dll - PostgreSQL client software.
If you know SQL Server, then use SQL Server Express edition. And probably stay with dbGo (ADO) components. PostgreSQL is quite different from SQL Server in many aspects, so you will need to spend the time to learn PostgreSQL. Which will be far more expensive than commercial libraries.

Zeos trunk works fine with Delphi XE. Don't let the "trunk" bit scare you. The mutation count is not that high.

Related

Referencing 3rd party components in Delphi 2005

I'm quite new to Delphi and I'm helping a team setting up a build server which are using Rad Studio 2005.
They have just bought DevExpress VCL and wants to use these. I would rather not have the component installed on the build server, but instead having them as a part of the source code and making sure that the project is using that version.
How is that done in Delphi?
We compiled all of our 3rd-party stuff into a BPL, then put that .bpl and corresponding .dcp and .dpr/.bdsproje into source control, so it gets delivered to the build server. Works well. In retrospect, it should have been a series of BPLs, divided by vendor, so that we could upgrade individual components/libraries without having to run regression tests on everything else.

ADO components in delphi

I am currently using BDE components to connect to a database in Delphi 5 professional version. My problem is that BDE components need BDE Administator to run the application on another machine. So I am planning to buy a new version of Delphi which contains ADO components.
Question: Are ADO components also having issues like the BDE? Do ADO components need any specific setup to run applications on another machine?
Thanks for the help.
All the components have issues in some point, in the case of ADO is very stable, but you can have some specific problems with the providers (like the infamous not support for blob fields in ORACLE using the Microsoft provider) but certainly is more recommendable use ADO instead of the deprecated BDE. About the dependencies, ADO uses providers to connect to the RDBMS, most of them are installed by MDAC (Microsoft Data Access Components) which is included in most of the Windows versions. So in most cases you will not need install any addtional component, at least which you want use a provider not inluded in MDAC like MySql, Firebird or others.
Sounds like if you posted two times the (almost) same question... with more focus on ADO this time.
As was written in the previous question, if you attempt to connect to an Oracle database using ADO or OleDB, you'll find out that all OleDB providers are buggy for handling Oracle BLOBs: Microsoft's version just do not handle them, and Oracle's version will randomly return null for 1/4 of rows... So IMHO ADO or OleDB are not a serious option for accessing Oracle database. :(
And if your purpose is to get rid of the BDE installation, you'll find out that the Oracle's OleDB provider is quite huge and that the BDE is much light and better... A standard Oracle's client installation containing the OleDB/ADO provider (which is not installed in the "Light" version of the Oracle's clients), needs a .zip setup of about 660 MB...
On real database data, I found out our Open Source direct access to Oracle to be 2 to 10 times faster than the OleDB provider, without the need to install this provider (nor the BDE). You can even use the Oracle Instant Client provided by Oracle which allows you to run your applications without installing the standard (huge) Oracle client or having an ORACLE_HOME. Just deliver the dll files in the same directory than your application, and it will work.
Of course, this is full Open Source, and works from Delphi 5 up to XE. So when your project may upgrade to a newer Delphi version, it will work. You are not tied to non-Unicode Delphi 5-Delphi 7 version of Oracle components, as you can found on Torry's, e.g. but those components may help you get rid of the BDE installation for an existing project.
If you don't use BLOBs in your database, you can use ADO. In this case, my advice is to read this post, and use TADODataset, which is available in Delphi 5.
Ok Naren, since you are on Oracle you can use this Oracle driver DOA. We use it exclusively in our Delphi projects.
All our Delphi projects are on Delphi 7 but we are converting all of it to Delphi XE now. When using DOA you do need to install the Oracle client libraries on the client machine. The upside is speed and Oracle support, so the DOA drivers don't need to work on the most common command set like ADO needs to, so the Oracle support is brilliant.

Anyone would like to share their experience using TFS for Application life cycle management

we are developing white label web and mobile healthcare application for our clients. our product is evolving rapidly and we are supporting existing clients and going to support new clients.
current development workflow involves SVN for source code, requirement documents tracking and mantis for defect tracking.
We are considering VS TFS 2010 based Application life cycle management for our organization. we are hoping that VS TFS 2010 will help us streamline the following
1) Requirements Management
2) Source code Version control
3) Build automation
4) Test management
just wondering is anybody have experience using VS TFS 2010 and would like to share their experiences? is there any worthwhile alternatives to VS TeamSystem?
Preface: This is a personal opinion and I have no ties to Microsoft other than that I develop with their tools for their platform, even though I come across as a Microsoft lover in this answer. (which I am - I love .NET development)
I haven't used TFS 2010, but I HAVE used the 2005 Team Suite including TFS and the Visual Studio versions supported. We didn't move forward to 2008 or 1020 because of how extraordinarily difficult the 2005 version was to install. However, once we got it installed... Loved it. The project management tools were intuitive, and worked well. Setting up builds was a breeze, and it did everything I wanted it to do simply and efficiently.
Since then, however, we've adopted open source tools to do the same type of stuff. As I said, the install of 2005 was a NIGHTMARE and even though the 2010 version of Team Foundation Server installs VERY easily (I tested it myself and demonstrated it to the poor team who helped with the 2005 version just to show them how much better it is), I was unable to convince my team to give it a second chance. They chose to stick with tools that didn't need to be upgraded as often, and that were easier to upgrade when it did need to be done.
If it were just me, I'd be using it. This is one of those things where things just work right, and work together seamlessly. And the available documentation (MSDN, videos, etc) is exhaustive. I doubt any other set of tools is as well-documented.
It's just too bad that the experience with the older version was so bad that nobody else here will give the newer version a fair shake.
As for alternatives - it's not open source, but Atlassian has a nice set of tools. They work well for Java and we're using some of them in our .NET shop. We're using SVN for source control. That's about the only thing I like better about our new environment than I did the Team System.
I started at a new company 2 months back that uses TFS 2010 exclusively (for source control and issue/task tracking), and I haven't been able to get comfortable with it. Previously, I've mainly used SVN for source control and either OnTime (by Axosoft) or Fogbugz (Joel Spolsky) and have loved them both.
I don't know if it's the way they're using TFS (branching is nothing as nice as it was in SVN... and they have Product Backlog Items, Sprint Backlog Items, Bugs, Impediments, and god knows what else to keep track of) but I find it way too convoluted.
I think the tools a developer uses should assist the dev, not get in the way of. If I have to stop and think about how to branch code or assign an issue, then something's wrong with my tools (or I just need to spend more time learning them... which doesn't make sense to me either).

is Delphi still the same (still run with no installed libraries)?

Back when I used Delphi (win32), programs made with it would run on windows, with no need to install any runtime libraries like .NET or Java(?). Is this still the case? If not, which language can do that?
Delphi executables don't have any external dependency.
It's true since Delphi 1 up to Delphi XE.
I just wrote a post on my blog about this fact I like very much in Delphi.
http://blog.synopse.info/post/2010/09/20/Dll-hell%2C-WinSXS-directory-and-Delphi-paradise
No dll hell with Delphi applications!
Deploying a Delphi application is very easy.
If you need some database access, you could need some additional components, like the BDE, or the ODBC drivers, or whatever...
But there are a lot of stand-alone frameworks, with no external dependency, available for Delphi. We provide one Client/Server Open Source solution, using SQLite3 as database storage. And one of great feature of SQLite3 is that it doesn't need to install any client software. Our framework provide the Client/Server features, in pure Delphi.
Both the language and the IDE had some serious improvements from Delphi 1.
To name a few extentions for the language:
Support for interfaces
Records with methods
Record and class helper functions
Annonymous functions
Generics
Hinting directives
There are also some IDE improvements.
Unicode support
More integrated tools
Usage of identifiers (2011).
There are still some things missing:
64 bit support
generics still have some bugs.
It is still the case for the "normal" Delphi, i.e. Delphi for Win32. There is also Delphi Prism which targets .NET for which it is obviously not the case.
Currently there's Delphi for Win32 available, which doesn't require any runtimes and Delphi Prism (for .NET application development). Delphi for 64-bit native Windows development is promised next year.
Well, Lazarus obviously :-)
Seriously, Delphi is fine, but before you buy a recent one, if you need win9x support, check thoroughly. (since the unicode versions might no longer support that)

Delphi: Moving away from VSS

We are team of few Delphi developers who have been using VSS since years (I know it's a pity), but we don't use any of the advanced features of VCS, so it was working fine in many cases (but some times it was driving me crazy :( ).
The good thing that we have with VSS that we use third-party plug-ins to integrate VSS with Delphi, which is working great, but now when our projects becomes larger, and we would like to move a way from VSS.
I have looked at few other VCS (free and commercial) and found most of them seems be made for Linux guys, and you have to use command line for many admin work(I know I'm windows guy :P).
What I'm looking for the new Version control that it should be easy to use and to maintain and Integrated nicely with Delphi IDE (D2007), or at least have a good UI for the Admins an developers.
Just use SVN and an excellent TortoiseSVN client which integrates with the Windows Explorer.
P.S. Found this question: What is the best set of tools to develop Win32 Delphi applications? and this Delphi IDE/TortoiseSVN integration tools in one of the answers: http://delphiaddinfortortoisesvn.tigris.org/
You should at least take a look at JVCS. It integrates with the Delphi IDE, it's written in Delphi and is open source, and you can choose from a number of databases including Firebird to store your archive in.
There is Team Coherence (http://www.teamcoherence.com/) which is written in Delphi and integrates with the IDE very well. We still use it. Support is patchy though.
Most people seem to be moving to SubVersion though.
Team Coherence is a good choice. They just released a new client, so it looks like support is alive and well.
Unless you are directly heading to SVN (which I wouldn't recommend, if you're thinking on something free go to Git or Mercurial) check Plastic SCM. Find a couple of Delphi specific tutorials here:
http://codicesoftware.blogspot.com/2008/06/branching-and-merging-with-delphi-part.html
http://codicesoftware.blogspot.com/2008/06/branching-and-merging-with-delphi-part_02.html
Our Delphi team recently (last year ) upgraded from VSS to Perforce which is an absolute joy to work with. It is expensive but is well worth it. It makes source code control one of the tools of your trade rather than a chore or a hinderance. It has good GUI tools, a great commandline when required and there is a free Delphi IDE integration available online.
It does take a bit of getting used to, but is worth putting in the effort when you get to the point where you can create branches with abandon and merge changes knowing you dont ever have to worry about losing any changes ever. Its fast, efficient and a pleasure to use.

Resources