Thank you every one for your comments!
Smile!
Jeneil
-----Original Message-----
From: William H. Du Chene [mailto:outatym1@ECENET.COM]
Sent: Friday, March 23, 2001 1:38 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic
**
Jeneil -
Remedy and VB are both fine tools. Personally, I think that there is a
little too much hipe around both of them. As always, there are zealots on
both sides. In the MS corner, we have Microsoft and company which would have
us believe that VB is capable of anything. On the other side, Remedy says
that they are the best for 'enterprise wide' and 'rapid solutions'. In
truth, I guess that it would be fair to say that they both have their
respective niches. There is a little overlap between the two and that is
where some people sometimes get hung-up. Selecting a tool to use should be
based upon the environment you have, your intended use and the user body.
Should you use Remedy, you will be using a tool which has been designed
since the early versions to work on a variety of database platforms, across
OS boundaries. The base system also has a fairly sophisticated data model.
As everyone on this list knows, administration of the server and the objects
in the database is fairly easy. (The arserverd process will add indexes,
drop tables, create views, ect.) If you have something new to build, Remedy
will take care of the behind-the-scenes database functions while development
goes on. From an application stand point, the end user gets a time-tested,
*hopefully* debugged tool that they can manipulate their records through
with just enough eye-candy to keep them happy. When it comes time to change
something in your app, you can fire up the admin tool and change it and have
that change visible to all users that connect to the server.
From a VB stand point, application development gets a little more hairy.
First, the developers *should* have a fairly stable data model to begin with
before development begins - especially if your project is large. This is
generally a wise idea so that they can plan for indexes on columns,
establish primary and foreign keys on tables, set up constraints, triggers,
stored procedures and the like for performance tuning reasons in the
database. When they are actually coding the application - developers have
to agree on a form design and feel. Next, they actually have to write the
code behind the events in the controls to get the app to work. This can be
an especially tedious task if they finish up coding all of the SQL inserts,
updates, and deletes by hand. (Depending on the db platform and controls
used.) So, once they get all of this done, you are left with connectivity.
Normally, most installations use the drivers that are native to the database
platform that they are using. In other words, the LAN tech has to install
the ODBC drivers before the new home-brew app can connect to the database.
This done, you are left with distribution. Is there enough time left in a
day to put together a new installation package and push it down to the
machines via novell when the users login? Having said all of this, there is
still the question of a change in your app. Whoops. Time to go through the
process - at least in part - all over again. Cross the fingers... and pray
that it all works.
There is an amusing twist to all of this - price. Certainly, Remedy is more
expensive, but on the flip side you can distribute the client wherever you
wish and as long as the user has a license and can reach your box, he/she
should be able to connect and use it. VB - the last time that I looked -
came in at 1600.00 a shot for each developer (Enterprise Edition.) Add to
this the cost of the licenses for the runtimes for the db platform that you
are using, and the connection licenses to the database itself. (Many
databases are licensed on the number of connections that they can have open
concurrently - using Remedy may use up a number of connections, but
certainly far fewer than having 50 people connect via ODBC to your database)
If you already have Remedy in place - up and going - then I would urge you
to run with it. If there are things that Remedy cannot do, then by all means
add a VB app to *compliment* your design. This is especially true if you
have a time frame to operate in, as development may (normally) unexpectedly
take longer than you have on a project.
Just my 2cents.... I welcome any questions, comments, ect.
Will
-----Original Message-----
From: Russell, Jeneil P WAMC-Ft Bragg
To: ARSLIST@LISTSERV.VISTAIT.COM
Date: Thursday, March 22, 2001 3:35 PM
Subject: Remedy vs. Visual Basic
>**
>
>Dear List,
>
>My department is making a decision as to whether we should use Remedy as
our
>primary developing tool or strickly Visual Basic programming (using Visual
>Studio). The resident VB expert argues that Remedy is limited and not
>robust enough to provide enterprise-wide solutions. I am trying to argue
>that we should continue using Remedy. Can I please have your opinions and
>comments? And if you have developed enterprise-wide solutions using
Remedy,
>what are they?
>
>Any thoughts greatly appreciated.
>
>Smile!
>Jeneil
>
>
>
>
Previous Topic
Index