DeskTop, SQL, or Other Option?? 
Author Message
 DeskTop, SQL, or Other Option??

Aloha!
Q. If I am moving an application from DOS based [Clipper, using LoadStone's
CDX (foxpro type) database driver] to WIndows based (Delphi 5) and MOST of
my clients use the application from remote locations (currently using remote
access software such as PCAnywhere, Closeup, etc.) and my long-term
intention is to make the application client-server, then;

    am I wasting time in converting the application to delphi using local
databases?

    should I go ahead and, since I'm making the conversion anyway, get the
SQL version of Delphi and, if so, what SQL server type do you
recommend?

#or#

Could I expect minimal amout of souce code changes to later change the
application to SQL?

#or#

Are there other methods, such as RAS, etc. that will enable my clients to
access the data from remote locations at a REASONABLE speed without the
application being SQL?  So far, I have had to steer my clients away from
doing anything remote access other than by strictly DOS due to speed
preformance.

Thanks In Advance,

Kumar

--
Database Designs
P. O. Box 1217
Kula, Hawaii  96790-1217



Wed, 18 Jun 1902 08:00:00 GMT  
 DeskTop, SQL, or Other Option??


Quote:
>Aloha!
>Q. If I am moving an application from DOS based [Clipper, using LoadStone's
>CDX (foxpro type) database driver] to WIndows based (Delphi 5) and MOST of
>my clients use the application from remote locations (currently using remote
>access software such as PCAnywhere, Closeup, etc.) and my long-term
>intention is to make the application client-server, then;

>    am I wasting time in converting the application to Delphi using local
>databases?

Probably... see below.

Quote:
>    should I go ahead and, since I'm making the conversion anyway, get the
>SQL version of Delphi and, if so, what SQL server type do you
>recommend?

You could start with InterBase... it's a clean SQL implementation.  DB
is solid... administration is easy.  Cost is very competitive.

Quote:
>#or#

>Could I expect minimal amout of souce code changes to later change the
>application to SQL?

Probably not.  Local database optimization (which I think is required
if you are to allow remote connections) is completely useless when
porting to C/S engines.  The former can be optimized by using TTables,
while the latter usually is speedier by using TQueries.

Quote:
>#or#

>Are there other methods, such as RAS, etc. that will enable my clients to
>access the data from remote locations at a REASONABLE speed without the
>application being SQL?  So far, I have had to steer my clients away from
>doing anything remote access other than by strictly DOS due to speed
>preformance.

I'd say no... SQL returns only the requested result set... access to
Paradox, dBase and other dbs require reading through tables and
indices, which will have to travel to the client for selection.
Unless you are very good at index definition and optimization this can
get very tricky.  You'd have to limit access only to indexed fields as
a single filter request may bog down the application.

A temporary solution could be to continue to use PCAnywhere or
something like that.  Use a local db and don't waste time to optimize
it.  Maybe you can start using queries directly, so as to reduce
porting costs later.  This way inefficencies are carried across the
remote connection, but are instead resolved on the PCAnywhere host PC
(that means either local or LAN).  The PCAnywhere (I assume that it
works as ReachOut) sends only graphics across the connection... the
application is actually executing on the host machine.

You could also think about using a three-tier solution like MIDAS.
The cons are that this is very expensive to deploy and not really that
easy and seamless to code.

Regards,

--
Marco Rocci
MicroEra srl
Turin, Italy
-----------------
vota contro lo SPAM su: http://www.politik-digital.de/spam/



Wed, 18 Jun 1902 08:00:00 GMT  
 DeskTop, SQL, or Other Option??


Quote:


> >Aloha!
> >Q. If I am moving an application from DOS based [Clipper, using
LoadStone's
> >CDX (foxpro type) database driver] to WIndows based (Delphi 5) and MOST
of
> >my clients use the application from remote locations (currently using
remote
> >access software such as PCAnywhere, Closeup, etc.) and my long-term
> >intention is to make the application client-server, then;

> >    am I wasting time in converting the application to Delphi using local
> >databases?

> Probably... see below.

Seems to me that in this case the local or CS decision is not really related
to the remote access. All you do with PC Anywhere is "take over" a PC,
right? System works just as it would if you were there sitting at the
network host PC, except your display is slower because you're sending the
screen changes and keystrokes over a phone line. I would just design the new
system ignoring the PCA issue, and make the database decision based on the
characteristics of the application.

Seems like, since you're converting a Clipper ap, unless you're planning on
adding a lot of new functionality, a local database - Paradox, Access, or my
favorite, DBISAM - should do just fine.

Robert



Wed, 18 Jun 1902 08:00:00 GMT  
 DeskTop, SQL, or Other Option??
Interbase would be my recommendation also,
via either InterbaseExpress (Delphi5) or
IBObjects (http://www.ibobjects.com).  They are
both solid no-BDE choices for what is in my
opinion THE client/server solution for sub 500
Simultaneous User database requirements.

GW.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Database Desktop (Open and Detach) option in Delphi 2.0 RunTime

2. Getting SQL from QBE queries similar to Database Desktop

3. Delphi Desktop and Sybase/SQL Server

4. Delphi 1 Desktop/MS SQL Server 6/6.5

5. SQL Server 7 Desktop and Delphi

6. Missing Database classes? (TDBForm and others)

7. How to lock a table of Interbase to avoid that others modify it

8. GRAPH.TPU and others

9. Have any others experienced this in pascal?

10. Humour: Pascal vs C (and others)

11. Have any others experienced this in pascal?

12. HELP!!: Displaying BITMAPS, and others

 

 
Powered by phpBB® Forum Software