Patrick
This raises a lot of issues, One which is signiificant (are you listening
Nick) is how little Borland do for us as developers, Because we are their
'clients'
it always seems to me that they are trying to extact revenues from us and
not seeing us a resource thru which their revenues can be increased. The
average IT manager out there has heard great things about delphi but
wouldn't have clue on how to get a project written in it. v. M$ products
which
every man and his dog (esp the dog) claims to be an expert in
>> 1. Obtain the services of a contracting firm in another part of the
country.
>> You can only go so far with remote working, unless you have full
administrative access to the machines the software is running on. Someone
would still have to >> physically install and set up the software in the
environment in which it is being used. One of the problems we have
encountered is that PC support staff out
>> there don't know anything about setting the BDE up on a network system.
I really think it is ironic that in the tech industry that you need someone
'onsite' for a small project like this - the software developer could be
anywhere in the
country as long as they can have a duplicate system in house, "setting the
BDE up on a network system" can be as simple as "running" 1 reg file
This is your prime solution
>> 2. Develop in house
I've seen everything from whole inventory systems written in excel macros to
the "parts manager" writing a whole account system in Access the problems
are not generally cost since it is hidden in the salary), The real issues
are
1/ Quality of the Software Design & Implementation and Doc's
2/ Risk Management, What happen when the 'guru' leaves
Re " inhouse stuff is already being done in MSAccess than any other database
(how many people do you know that use Corel Paradox for their organisation's
internal databases, huh?)"
If you were starting a green field project now and suggested either of those
databases, I'd have to question your sanity! The are so many free
SQL databases that the concept of using an ISAM is simply idiotic. This
strangely is causing M$ problems as well, They have been very sucessful
infiltrating Access (& VB) into organisations and now they realise that they
don't really want to support these products long term. The pressure
they a putting on VB dev's (with VB.NET) is not accidental, it would suit M$
if they all ported to VC or C#. Simlar machevalian machinations
are occuring with Access, look for subtle functionality drops in the Jet
engine v running Access with MS SQL, a typical M$ plot to use one
products dominance (Access in the Desktop Database) to lend support for
another under threat (MS SQL). This would also give credance to
all the 'weekend' developers who write complicated software in MS Access,
previously these products could be dismissed due to crap
dbms they were bound to, More difficult if it is MS SQL, Result a lot of
crap software and database designs
>> 3. Port software to a different development environment.
For all the reasons above DONT DO IT, This may sound arrogant but having a
product developed in a minority system (Delphi) may
in the long term save you money.for the following reasons
1/ Generally Delphi developers are smarter because they have made a choice
not based on "nobody ever go fired for buying M$"
2/ Less likely to have some idiot 'fiddle' with the project
3/ The resultant code is morew reliable
4/ The code may be portable (providing you use CLX based comp libs or oners
that are likely to be ported to CLX)
Neven
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
