Board index » delphi » Delphi Client Server Development

Delphi Client Server Development

I have been programming in Delphi for hobbyist entertainment for few years now
and have decided it is time that I now started using Delphi for something more
productive.  I hope to persuade the Company that I work for to invest in
developing a new version of our core product using a Delphi based Client.
This will interface to an Oracle database (at least to start with) which will
- initially - be running on a networked Unix server.

I need advice and examples on the best methods to adopt to achieve excellent
results and have several questions.

As I only have Delphi 2 still should I upgrade ? And will I need the
Client/Server version of Delphi 4 ?

What methods to communicate with Oracle are available and which is the best
(in terms of simplicity, useability, power and performance) ?  Is ODBC usable
? Should I develop a custom OCI interface ? Are there native BDE drivers ?

What is the best method of achieving true RAD as far as forms and reports are
concerned ?  Should we develop each form as a unique instance or spend time
developing a new form class that handles input and navigation of its children
components better - validation, clicking to skip fields etc..  Is there
distance in developing custom components for common Fields in the database so
form creation would become truly a matter of drag and drop ?

What components or suite of components are recommended for speeding this
development ?

Are there some good sources of information you would recommend ?

I would appreciate anyone's comment and suggestions.  I think Delphi would be
the most powerful tool to use for a DB client and would enjoy developing a
real application in Delphi enormously.

Appologies if some of you recognise this as a similar post to one I posted a
long time ago.  This time I am determined to push this through the whole way
and I need to get all of my facts right to guarantee persuasion of the powers
that be.

TIA

---------------------------------------------------------------------------
Andrew Porter
http://www.defsdoor.demon.co.uk

 

Re:Delphi Client Server Development


Quote
Andrew Porter wrote in message <36ace387.43756821@defsdoor>...
>I have been programming in Delphi for hobbyist entertainment for few years
now
>and have decided it is time that I now started using Delphi for something
more
>productive.  I hope to persuade the Company that I work for to invest in
>developing a new version of our core product using a Delphi based Client.
>This will interface to an Oracle database (at least to start with) which
will
>- initially - be running on a networked Unix server.

I have just completed a major project using Delphi/Oracle with the back end
on a fairly large Sun box.

Quote

>I need advice and examples on the best methods to adopt to achieve
excellent
>results and have several questions.

>As I only have Delphi 2 still should I upgrade ? And will I need the
>Client/Server version of Delphi 4 ?

We used Delphi 3 Professional.  The extra stuff in Client/Server was not
warranted.  ODBC connections to Oracle proved just as fast as links through
the D3 C/S "native" drivers.

Quote

>What methods to communicate with Oracle are available and which is the best
>(in terms of simplicity, useability, power and performance) ?  Is ODBC
usable
>? Should I develop a custom OCI interface ? Are there native BDE drivers ?

D3 C/S would probably have allowed us to pass through SQL to be completely
evaluated at the server end (to take advantage of fancy Oracle extensions)
but with access to the back end, procedures can be written there.

Quote
>What is the best method of achieving true RAD as far as forms and reports
are
>concerned ?

Have a true RAD perspective on the project.

Quote
>  Should we develop each form as a unique instance or spend time
>developing a new form class that handles input and navigation of its
children
>components better - validation, clicking to skip fields etc..  Is there
>distance in developing custom components for common Fields in the database
so
>form creation would become truly a matter of drag and drop ?

Depends on the economies of scale you're going to achieve.  Do whatever
makes the project cheaper in the time frame that you can justify.
Regardless of whatever anyone says, the ONLY consideration is to make the
project cheaper.

Cheaper to design
Cheaper to code
Cheaper to train for
cheaper to maintain
cheaper to port
cheaper to enhance
cheaper to rewrite
cheaper to replace

(Most people only consider the second -- but cheaper is a project lifestyle
issue)

Quote
>What components or suite of components are recommended for speeding this
>development ?

Whatever makes it cheaper :-)  Seriously, none is a very good start.

Quote
>Are there some good sources of information you would recommend ?

Are you an IT person?

Quote
>I would appreciate anyone's comment and suggestions.  I think Delphi would
be
>the most powerful tool to use for a DB client and would enjoy developing a
>real application in Delphi enormously.

I don't think Delphi is anywhere near the most powerful tool for DB client.
There were tools I was using in 1985 (and they still exist) that completely
blow Delphi out of the water if the consideration is limited to pure DB
systems.

HOWEVER, if you need some special flexibility, the need to also write some
"real" code to do something clever, then Delphi starts to show it's power.

Quote
>Appologies if some of you recognise this as a similar post to one I posted
a
>long time ago.  This time I am determined to push this through the whole
way
>and I need to get all of my facts right to guarantee persuasion of the
powers
>that be.

One word of caution.  If you're not actually a part of the IT section of
this company tread VERY carefully.  Do not follow the example of a person I
had some contact with at a previous place of employment who stated (1996)
that "I could write a better system on my Commodore 64" -- we believe he was
serious.

He was laughed at, not because of his choice of platform, but for technical
issues such as:  static data required by system exceeds C64 disk drive size,
lack of suitable database drivers (!), and difficulty in networking.

Do your homwork before you make this suggestion.

Steve

Re:Delphi Client Server Development


On Tue, 26 Jan 1999 08:33:53 +0800, "Steve Hodges" <ste...@excalibur.com.au>
wrote:

Quote

>We used Delphi 3 Professional.  The extra stuff in Client/Server was not
>warranted.  ODBC connections to Oracle proved just as fast as links through
>the D3 C/S "native" drivers.

Is ODBC really that capable ?  And is the mid-term life expectancy of ODBC
long enough to safely begin a new project that hope to have a minimum life
expectancy (before major rewrites) of 5 years.

Quote

>D3 C/S would probably have allowed us to pass through SQL to be completely
>evaluated at the server end (to take advantage of fancy Oracle extensions)
>but with access to the back end, procedures can be written there.

Are there safe ways to handle database integrity violations ?  And a way to
interpret the error messages from Oracle into sensible messages for end-users
?

Quote

>Depends on the economies of scale you're going to achieve.  Do whatever
>makes the project cheaper in the time frame that you can justify.
>Regardless of whatever anyone says, the ONLY consideration is to make the
>project cheaper.

>Cheaper to design
>Cheaper to code
>Cheaper to train for
>cheaper to maintain
>cheaper to port
>cheaper to enhance
>cheaper to rewrite
>cheaper to replace

>(Most people only consider the second -- but cheaper is a project lifestyle
>issue)

Hmmm, I might argue with you on this one but I think our different ideals
actually result in the same long-term end result.  I have always believed in
making the product 'better' (the best in all aspects) and letting its end-user
cost justify the additional development costs.  If he product is so much
better than the competition it will sell itself.  A ball park figure for this
system's sale price would be in the 200,000 pounds upwards league with monthly
recurring charges, depending on the size of the customer (typically 150 upto
400 users).  We are in a very specialised marketplace that has been in a 15
year boom worldwide and our existing products have features that none of our
competitors can offer.

Quote

>Are you an IT person?

Yes.

Quote

>I don't think Delphi is anywhere near the most powerful tool for DB client.
>There were tools I was using in 1985 (and they still exist) that completely
>blow Delphi out of the water if the consideration is limited to pure DB
>systems.

>HOWEVER, if you need some special flexibility, the need to also write some
>"real" code to do something clever, then Delphi starts to show it's power.

Should I be looking at other tools then ?  What would you suggest ?  We don't
need to do anything 'clever' - although I am currently designing a user
interface that is almost pure gui - very little keyboard input will be
required.  Developer 2000 is an obvious choice but I was looking at developing
something quite special.

Quote

>Do your homwork before you make this suggestion.

This is all part of my homework :)

Thanks
---------------------------------------------------------------------------
Andrew Porter
http://www.defsdoor.demon.co.uk

Re:Delphi Client Server Development


Quote
>>We used Delphi 3 Professional.  The extra stuff in Client/Server was not
>>warranted.  ODBC connections to Oracle proved just as fast as links
through
>>the D3 C/S "native" drivers.
>Is ODBC really that capable ?  And is the mid-term life expectancy of ODBC
>long enough to safely begin a new project that hope to have a minimum life
>expectancy (before major rewrites) of 5 years.

It works, it's cheap, and how do I know that Delphi native drivers are going
to continue to work for 5 years?

Quote
>>D3 C/S would probably have allowed us to pass through SQL to be completely
>>evaluated at the server end (to take advantage of fancy Oracle extensions)
>>but with access to the back end, procedures can be written there.
>Are there safe ways to handle database integrity violations ?  And a way to
>interpret the error messages from Oracle into sensible messages for
end-users
>?

My thought is that Integrity violations should only occur in 2
circumstances:
1) your code is doing something wrong
2) the database is not logically consistent

in either case an unexpected error should be reported to the user containing
the full text of whatever comes from the database (along with a message
about what you were trying to do, the fact that everything is now rolled
back (or not) and what action the user should take (call support))

integrity errors should always be unexpected.  you should NEVER code so that
the database does the primary integrity checks.  Integrity constraints are
there to protect the data (or DBA) from programmers errors, not to provide
routine validation for users.

Quote
>>Depends on the economies of scale you're going to achieve.  Do whatever
>>makes the project cheaper in the time frame that you can justify.
>>Regardless of whatever anyone says, the ONLY consideration is to make the
>>project cheaper.

>>Cheaper to design
>>Cheaper to code
>>Cheaper to train for
>>cheaper to maintain
>>cheaper to port
>>cheaper to enhance
>>cheaper to rewrite
>>cheaper to replace

>>(Most people only consider the second -- but cheaper is a project
lifestyle
>>issue)
>Hmmm, I might argue with you on this one but I think our different ideals
>actually result in the same long-term end result.  I have always believed
in
>making the product 'better' (the best in all aspects) and letting its
end-user
>cost justify the additional development costs.  If he product is so much
>better than the competition it will sell itself.  A ball park figure for
this
>system's sale price would be in the 200,000 pounds upwards league with
monthly
>recurring charges, depending on the size of the customer (typically 150
upto
>400 users).  We are in a very specialised marketplace that has been in a 15
>year boom worldwide and our existing products have features that none of
our
>competitors can offer.

You've just made the same argument.  the only difference is that "cheaper"
becomes "more profitable" when you contemplate selling it.

Quote
>>Are you an IT person?
>Yes.

so am I, strangly enough...

Quote
>>I don't think Delphi is anywhere near the most powerful tool for DB
client.
>>There were tools I was using in 1985 (and they still exist) that
completely
>>blow Delphi out of the water if the consideration is limited to pure DB
>>systems.

>>HOWEVER, if you need some special flexibility, the need to also write some
>>"real" code to do something clever, then Delphi starts to show it's power.

>Should I be looking at other tools then ?

Yes, always.  But you only change tools if it will be cheaper.  Will the
benefit of changing tools outweigh the cost of becomming proficient,
rewriting common routines, maintaining systems in multiple environments
etc...

Quote
> What would you suggest ?  We don't
>need to do anything 'clever' - although I am currently designing a user
>interface that is almost pure gui - very little keyboard input will be
>required.  Developer 2000 is an obvious choice but I was looking at
developing
>something quite special.

Delphi probably has one of the lowest overheads in writing DB code for a 3GL
that I've come across.  But that still makes it way less productive than a
4GL for writing pure database applications.  It does, however, make up for
this in execution speed.  And if the application is not going to have the
database as a bottleneck, then Delphi will provide a performance benefit
over most 4GL's.  When "something special" starts to take on features like
communicating with other applications (say word or excel) or making the
application "smart" then Delphi comes into its own.

THE major problem is that you can't use Delphi on an non wintel platform.

Steve

Other Threads