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

This sounds lilke politics to me. Last year it was Clinto bashing. Now
its time for Bush bashing. Somehow, the truth no longer matters. Truth
has become relative.

I bet the VB person knows little about Remedy and he is a Vb fan. People
with limited knowledge, experience
and abilities have a tendency to become very attached to what they know.

Try this approach.
Mr Vb, i know you can do this using Vb, but do you want to? It this the
easy way.
Is this the fastest way. Remedy is not just a help desk tool it is also
a database interface tool.
Remedy can't do everything but it can do alot of things. Let's use both.
Let's use Remedy as the
db interface and use VB when we need too.

The winner of your war will NOT be the person that is correct, it will be
the person with the most polical
influence. You better line up your allies.




"Russell, Jeneil P WAMC-Ft Bragg"
@LISTSERV.VISTAIT.COM> on 03/22/2001 01:28:38 PM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:

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

Rick Cook
Remedy Consultant
Herrick Douglass Technology Development

-----Original Message-----
From: Russell, Jeneil P WAMC-Ft Bragg
[ mailto:Jeneil.Russell@NA.AMEDD.ARMY.MIL]
Sent: Thursday, March 22, 2001 1:29 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
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

The bottom line is you already own Remedy..... good, bad, or indifferent, its a bad decision to disregard that and start from scratch for something you can use Remedy to accomplish.

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Rick Cook
Sent: Thursday, March 22, 2001 4:08 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic



Amazing, isn't it? When all one has is a hammer, everything looks like a nail... Could Remedy-type functions be built in VB? Probably. Why do it that way, unless you have a system so simple that you could put it on an Access Database?

Rick Cook
Remedy Consultant
Herrick Douglass Technology Development

-----Original Message-----
From: Russell, Jeneil P WAMC-Ft Bragg
[ mailto:Jeneil.Russell@NA.AMEDD.ARMY.MIL]
Sent: Thursday, March 22, 2001 1:29 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
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

Suggestion, ask the VB programmer how long it takes to update a field on the production system, add new criteria to a program for a menu selection, drop a field from use, etc. Like Rick says, why not use Access, or for that matter Foxpro, or DataEase, or any other product. Sometimes, it is a matter of what people are most confortable with.

Make sure your people know what Remedy is, how it works, how readily it can be modified, how it can be updated, and emphasize it is data - driven.. It always seems, management looks for that "hammer", and never realizes they already have one like Rick mentions, and then find out it takes more than a "hammer" to get the job done. A good Remedy Debvlioper knows when to supplement Remedy with addtional interfaces, and VB is used by some, then there is Perl, or for that Matter a good old "C" program using Remedy APIs. The fundamental needs, or should I day the engine is their, all one needs to do is tune it up, add some "neet" stull, and you're off and running.

Another thought, how often does a VB prgram get compiled, before it runs right. Interesting question. Then how long does it take to find the problems, and fix them, on the fly.

Terrence J Hensley
Uni-Data Remedy Consultant
513-697-9799

Check the possibilities:
http://www.sixfigureincome.com/?1239599



-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Rick Cook
Sent: Thursday, March 22, 2001 17:08
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic



Amazing, isn't it? When all one has is a hammer, everything looks like a nail... Could Remedy-type functions be built in VB? Probably. Why do it that way, unless you have a system so simple that you could put it on an Access Database?

Rick Cook
Remedy Consultant
Herrick Douglass Technology Development

-----Original Message-----
From: Russell, Jeneil P WAMC-Ft Bragg
[ mailto:Jeneil.Russell@NA.AMEDD.ARMY.MIL]
Sent: Thursday, March 22, 2001 1:29 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
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

David Charters

----- Original Message -----
From: Tim Button
To: ARSLIST@LISTSERV.VISTAIT.COM
Sent: Thursday, March 22, 2001 6:06 PM
Subject: Re: Remedy vs. Visual Basic

If you have already invested the cost of servers, licenses, and development/administration skill in Remedy, why not continue to do it in Remedy? We all will admit that there are different kinds of tools for different needs.

The bottom line is you already own Remedy..... good, bad, or indifferent, its a bad decision to disregard that and start from scratch for something you can use Remedy to accomplish.

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Rick Cook
Sent: Thursday, March 22, 2001 4:08 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic



Amazing, isn't it? When all one has is a hammer, everything looks like a nail... Could Remedy-type functions be built in VB? Probably. Why do it that way, unless you have a system so simple that you could put it on an Access Database?

Rick Cook
Remedy Consultant
Herrick Douglass Technology Development

-----Original Message-----
From: Russell, Jeneil P WAMC-Ft Bragg
[ mailto:Jeneil.Russell@NA.AMEDD.ARMY.MIL]
Sent: Thursday, March 22, 2001 1:29 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
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

I agree,

A couple of other factors to take in are

The time taken by a Remedy Administrator to make a change vs your VB guy,
who's probably head down in other work and may schedule you in some months
hence

What the heck do you do when he resigns, leaving you, like most VB techies,
with a heap of uncommented code. It's easier to find Remedy replacements who
can find their way around a Remedy system with the help of log files fairly
quickly. To me, this is your biggest exposure.

HTH

John

-----Original Message-----
From: Greg Gibson [mailto:Greg.Gibson@HSC.COM]
Sent: 23 March 2001 10:07
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

This sounds lilke politics to me. Last year it was Clinto bashing. Now
its time for Bush bashing. Somehow, the truth no longer matters. Truth
has become relative.

I bet the VB person knows little about Remedy and he is a Vb fan. People
with limited knowledge, experience
and abilities have a tendency to become very attached to what they know.

Try this approach.
Mr Vb, i know you can do this using Vb, but do you want to? It this the
easy way.
Is this the fastest way. Remedy is not just a help desk tool it is also
a database interface tool.
Remedy can't do everything but it can do alot of things. Let's use both.
Let's use Remedy as the
db interface and use VB when we need too.

The winner of your war will NOT be the person that is correct, it will be
the person with the most polical
influence. You better line up your allies.




"Russell, Jeneil P WAMC-Ft Bragg"
@LISTSERV.VISTAIT.COM> on 03/22/2001 01:28:38 PM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:

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

Sounds like VB guy is looking for job security...


----- Original Message -----
From: "Russell, Jeneil P WAMC-Ft Bragg"
To:
Sent: Thursday, March 22, 2001 4:28 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
>
>
>

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
>
>
>

>

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
>
>
>

>

Jeneil,
First, I agree with Will, he's covered the topic very well. In addition, one of
the great strengths of AR System is that the application is stored as data
in the SQL database. Unlike VB, which must have the client-side application
program downloaded to each user's PC, AR System automatically downloads
the latest version (if needed) when the user logs in. The cost and hassle of
upgrading all those PCs - after even minor changes - pretty much justifies
using
(my favorite tool) AR System. Using ARWeb or RemedyWeb with 'public' licenses
makes AR System as cost-effective, or better, than that product from the
Redmond
Monopoly.

... and that's my 2-cents ;-}

Joel (NOT the moderator in this posting)

At 12:37 AM 3/23/2001 -0600, William H. Du Chene wrote:
>**
>
>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
> >
> >
> >
>
> >
>
>
>
>

Joel D. Sender
ARSlist Moderator
For Help with your subscription: JDSender@earthlink.net
www.ARSlist.org


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_____________________________

I don't think it's fair to compare Remedy with VB. Each one is in different
worlds!
Remedy is packaged apps and VB is development tool with which you can develop
anything you want.
If you want to develop with Remedy as development tool, you are limited to use
Remedy concepts, which are very UN Object oriented and UN RDBMS concepts. The DB
is designe to facilitate the Remedy concepts not RDBMS concepts. Remedy is good
for what they meant Helpdesk, AM, CM ..

VB is devlopement like any other GUI tool ( Powerbuilder, Delphi ). You design,
build apps from scratch. You build the Database from scratch too. Again, they
are completely different!
Regards...
Ravi Bommareddy
Remedy Admn. & DBA
JWT





"Joel D. Sender" @LISTSERV.VISTAIT.COM> on 03/23/2001
03:07:36 PM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


**

Jeneil,
First, I agree with Will, he's covered the topic very well. In addition, one of
the great strengths of AR System is that the application is stored as data
in the SQL database. Unlike VB, which must have the client-side application
program downloaded to each user's PC, AR System automatically downloads
the latest version (if needed) when the user logs in. The cost and hassle of
upgrading all those PCs - after even minor changes - pretty much justifies
using
(my favorite tool) AR System. Using ARWeb or RemedyWeb with 'public' licenses
makes AR System as cost-effective, or better, than that product from the
Redmond
Monopoly.

... and that's my 2-cents ;-}

Joel (NOT the moderator in this posting)

At 12:37 AM 3/23/2001 -0600, William H. Du Chene wrote:
>**
>
>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
> >
> >
> >
>
> >
>
>
>
>

Joel D. Sender
ARSlist Moderator
For Help with your subscription: JDSender@earthlink.net
www.ARSlist.org


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

If all you can think to use Remedy for is Helpdesk, Asset of Change. Then
you are not thinking hard enough. Any application that requires Actions &
Tracking can be written in Remedy. My 2 cents !

Doug Tanner
Ultimate Workflow Integration Partners, Inc.
President
RAC / Remedy Instructor
(704) 947 - 0741
(704) 947 - 0781 Fax





-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
Sent: Monday, March 26, 2001 9:56 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

I don't think it's fair to compare Remedy with VB. Each one is in different
worlds!
Remedy is packaged apps and VB is development tool with which you can
develop
anything you want.
If you want to develop with Remedy as development tool, you are limited to
use
Remedy concepts, which are very UN Object oriented and UN RDBMS concepts.
The DB
is designe to facilitate the Remedy concepts not RDBMS concepts. Remedy is
good
for what they meant Helpdesk, AM, CM ..

VB is devlopement like any other GUI tool ( Powerbuilder, Delphi ). You
design,
build apps from scratch. You build the Database from scratch too. Again,
they
are completely different!
Regards...
Ravi Bommareddy
Remedy Admn. & DBA
JWT





"Joel D. Sender" @LISTSERV.VISTAIT.COM> on 03/23/2001
03:07:36 PM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


**

Jeneil,
First, I agree with Will, he's covered the topic very well. In addition, one
of
the great strengths of AR System is that the application is stored as data
in the SQL database. Unlike VB, which must have the client-side application
program downloaded to each user's PC, AR System automatically downloads
the latest version (if needed) when the user logs in. The cost and hassle of
upgrading all those PCs - after even minor changes - pretty much justifies
using
(my favorite tool) AR System. Using ARWeb or RemedyWeb with 'public'
licenses
makes AR System as cost-effective, or better, than that product from the
Redmond
Monopoly.

... and that's my 2-cents ;-}

Joel (NOT the moderator in this posting)

At 12:37 AM 3/23/2001 -0600, William H. Du Chene wrote:
>**
>
>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
> >
> >
> >
>
> >
>
>
>
>

Joel D. Sender
ARSlist Moderator
For Help with your subscription: JDSender@earthlink.net
www.ARSlist.org


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


________________
_____________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

Fair, hmmm, thats an interesting perception.

Remedy provides some degree of uniformity in creating fields, but this can
also be called an advantage. Ones development time can be significantly
reduced as the system defines specific fields automatically. All you have
to do is set the final parameters, not design the code that creates the
objects. There are other aspects as well, but no need togo there here.

And don't forget there are a lot of "Applications" created using VB. Ever
try fine tuning one! Or even tried modififying one to work with Remedy
where it didn't before?

Like Doug Tanner says in another email, yes Remedy does have available
pre-defined aplications, just like there are pre-defined VB applicaitons,
but with the Remedy Applications, you can readily get into them and make
changes as needed. Are the VB applications limited to the ones created by a
specific group of people? Of course not, neither is Remedy. Try thinking of
Remedy as another software development environment.

Remedy ARS should be compared to other development environments, like Vusal
Basic, C++ even, or Basic. They all make a computer do something
differently, but yet they are the same in that they all tell the computer at
the OS and hardware level pretty much the same thing.


Terrence J Hensley
Uni-Data Remedy Consultant

Check the possibilities:
http://www.sixfigureincome.com/?1239599

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> Sent: Monday, March 26, 2001 09:56
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> I don't think it's fair to compare Remedy with VB. Each one is in
> different
> worlds!
> Remedy is packaged apps and VB is development tool with which you
> can develop
> anything you want.
> If you want to develop with Remedy as development tool, you are
> limited to use
> Remedy concepts, which are very UN Object oriented and UN RDBMS
> concepts. The DB
> is designe to facilitate the Remedy concepts not RDBMS concepts.
> Remedy is good
> for what they meant Helpdesk, AM, CM ..
>
> VB is devlopement like any other GUI tool ( Powerbuilder, Delphi
> ). You design,
> build apps from scratch. You build the Database from scratch too.
> Again, they
> are completely different!
> Regards...
> Ravi Bommareddy
> Remedy Admn. & DBA
> JWT
>
>
>
>
>
> "Joel D. Sender" @LISTSERV.VISTAIT.COM> on 03/23/2001
> 03:07:36 PM
>
> Please respond to "Action Request System discussion list(ARSList)"
>
>
> Sent by: "Action Request System discussion list(ARSList)"
>
>
>
> To: ARSLIST@LISTSERV.VISTAIT.COM
> cc:
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> Jeneil,
> First, I agree with Will, he's covered the topic very well. In
> addition, one of
> the great strengths of AR System is that the application is stored as data
> in the SQL database. Unlike VB, which must have the client-side
> application
> program downloaded to each user's PC, AR System automatically downloads
> the latest version (if needed) when the user logs in. The cost
> and hassle of
> upgrading all those PCs - after even minor changes - pretty much justifies
> using
> (my favorite tool) AR System. Using ARWeb or RemedyWeb with
> 'public' licenses
> makes AR System as cost-effective, or better, than that product from the
> Redmond
> Monopoly.
>
> ... and that's my 2-cents ;-}
>
> Joel (NOT the moderator in this posting)
>
> At 12:37 AM 3/23/2001 -0600, William H. Du Chene wrote:
> >**
> >
> >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
> > >
> > >
> > >
> >
> > >
> >
> >
> >
> >
>
> Joel D. Sender
> ARSlist Moderator
> For Help with your subscription: JDSender@earthlink.net
> www.ARSlist.org
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ______
> _______________________
>
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org
>
> ______
> _______________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

_____________________________

In the Pre-Defined VB Applications
I would Think someone (Remedy included) Could or should already
have BEEN inspired to Create a Module (so to speak) that is Configurable
that would give predefined active links Married to Predefined VB
that is configurable to the location etc.. for Increased functionality
and usability. Most Certainly SOMEONE OUT THEIR is going in this
direction???
Ready to be 1. the first, 2. the best , and ready to SELL you their APP !!

-----Original Message-----
From: Terrence J Hensley [mailto:thensley@IX.NETCOM.COM]
Sent: Monday, March 26, 2001 10:40 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

Fair, hmmm, thats an interesting perception.

Remedy provides some degree of uniformity in creating fields, but this can
also be called an advantage. Ones development time can be significantly
reduced as the system defines specific fields automatically. All you have
to do is set the final parameters, not design the code that creates the
objects. There are other aspects as well, but no need togo there here.

And don't forget there are a lot of "Applications" created using VB. Ever
try fine tuning one! Or even tried modififying one to work with Remedy
where it didn't before?

Like Doug Tanner says in another email, yes Remedy does have available
pre-defined aplications, just like there are pre-defined VB applicaitons,
but with the Remedy Applications, you can readily get into them and make
changes as needed. Are the VB applications limited to the ones created by a
specific group of people? Of course not, neither is Remedy. Try thinking of
Remedy as another software development environment.

Remedy ARS should be compared to other development environments, like Vusal
Basic, C++ even, or Basic. They all make a computer do something
differently, but yet they are the same in that they all tell the computer at
the OS and hardware level pretty much the same thing.


Terrence J Hensley
Uni-Data Remedy Consultant

Check the possibilities:
http://www.sixfigureincome.com/?1239599

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> Sent: Monday, March 26, 2001 09:56
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> I don't think it's fair to compare Remedy with VB. Each one is in
> different
> worlds!
> Remedy is packaged apps and VB is development tool with which you
> can develop
> anything you want.
> If you want to develop with Remedy as development tool, you are
> limited to use
> Remedy concepts, which are very UN Object oriented and UN RDBMS
> concepts. The DB
> is designe to facilitate the Remedy concepts not RDBMS concepts.
> Remedy is good
> for what they meant Helpdesk, AM, CM ..
>
> VB is devlopement like any other GUI tool ( Powerbuilder, Delphi
> ). You design,
> build apps from scratch. You build the Database from scratch too.
> Again, they
> are completely different!
> Regards...
> Ravi Bommareddy
> Remedy Admn. & DBA
> JWT
>
>
>
>
>
> "Joel D. Sender" @LISTSERV.VISTAIT.COM> on 03/23/2001
> 03:07:36 PM
>
> Please respond to "Action Request System discussion list(ARSList)"
>
>
> Sent by: "Action Request System discussion list(ARSList)"
>
>
>
> To: ARSLIST@LISTSERV.VISTAIT.COM
> cc:
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> Jeneil,
> First, I agree with Will, he's covered the topic very well. In
> addition, one of
> the great strengths of AR System is that the application is stored as data
> in the SQL database. Unlike VB, which must have the client-side
> application
> program downloaded to each user's PC, AR System automatically downloads
> the latest version (if needed) when the user logs in. The cost
> and hassle of
> upgrading all those PCs - after even minor changes - pretty much justifies
> using
> (my favorite tool) AR System. Using ARWeb or RemedyWeb with
> 'public' licenses
> makes AR System as cost-effective, or better, than that product from the
> Redmond
> Monopoly.
>
> ... and that's my 2-cents ;-}
>
> Joel (NOT the moderator in this posting)
>
> At 12:37 AM 3/23/2001 -0600, William H. Du Chene wrote:
> >**
> >
> >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
> > >
> > >
> > >
> >
> > >
> >
> >
> >
> >
>
> Joel D. Sender
> ARSlist Moderator
> For Help with your subscription: JDSender@earthlink.net
> www.ARSlist.org
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ______
> _______________________
>
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org
>
> ______
> _______________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

You're right about Remedy. If you can track HD calls or Assets, you can use this
to any other actions & tracking system.
But the business world apps are not just actions and tracking!
Ravi Bommareddy
Remedy Admn. & DBA
JWT





Douglas Tanner @LISTSERV.VISTAIT.COM> on 03/26/2001
11:17:30 AM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


**

If all you can think to use Remedy for is Helpdesk, Asset of Change. Then
you are not thinking hard enough. Any application that requires Actions &
Tracking can be written in Remedy. My 2 cents !

Doug Tanner
Ultimate Workflow Integration Partners, Inc.
President
RAC / Remedy Instructor
(704) 947 - 0741
(704) 947 - 0781 Fax





-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
Sent: Monday, March 26, 2001 9:56 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

I don't think it's fair to compare Remedy with VB. Each one is in different
worlds!
Remedy is packaged apps and VB is development tool with which you can
develop
anything you want.
If you want to develop with Remedy as development tool, you are limited to
use
Remedy concepts, which are very UN Object oriented and UN RDBMS concepts.
The DB
is designe to facilitate the Remedy concepts not RDBMS concepts. Remedy is
good
for what they meant Helpdesk, AM, CM ..

VB is devlopement like any other GUI tool ( Powerbuilder, Delphi ). You
design,
build apps from scratch. You build the Database from scratch too. Again,
they
are completely different!
Regards...
Ravi Bommareddy
Remedy Admn. & DBA
JWT





"Joel D. Sender" @LISTSERV.VISTAIT.COM> on 03/23/2001
03:07:36 PM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


**

Jeneil,
First, I agree with Will, he's covered the topic very well. In addition, one
of
the great strengths of AR System is that the application is stored as data
in the SQL database. Unlike VB, which must have the client-side application
program downloaded to each user's PC, AR System automatically downloads
the latest version (if needed) when the user logs in. The cost and hassle of
upgrading all those PCs - after even minor changes - pretty much justifies
using
(my favorite tool) AR System. Using ARWeb or RemedyWeb with 'public'
licenses
makes AR System as cost-effective, or better, than that product from the
Redmond
Monopoly.

... and that's my 2-cents ;-}

Joel (NOT the moderator in this posting)

At 12:37 AM 3/23/2001 -0600, William H. Du Chene wrote:
>**
>
>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
> >
> >
> >
>
> >
>
>
>
>

Joel D. Sender
ARSlist Moderator
For Help with your subscription: JDSender@earthlink.net
www.ARSlist.org


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


________________
_____________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

"Remedy ARS should be compared to other development environments, like Vusal
Basic, C++ even, or Basic. They all make a computer do something
differently"

Yes, in End user terms we can this, "Remedy is also a development tool"

But if you look in depth about all this programming and Database concepts, then
you will see the difference. How many of you agree Remedy is not Object oriented
programming tool. Remedy is meant for non programmers to make life easy. They
don't need to know what is OOP, RDBMS, table space, primary keys, foreign keys,
encapsulation, inheritance, binding, loops, parent-child relation ships and
there are tons of things remedy developer doesn't need to know. You can say,
yah! that's good, I don't need to know all those". Well, it's up to you. If you
really want to feel or do the things more amazingly, you have to know C or C++
or JAVA or any other OOP tool with strong DB principles

Also, all these tools develops applications with or with out any database @ it's
background. i.e. your front end tool doesn't define your database. You design
your db separately which will address all your business needs and will follow
strict standards and rules. Where as in Remedy, you develop your db along with
your app. To use a table in remedy you have to create it through remedy. And you
don't know what's going on in db when you create a table. How many of we think
about indexes or table spaces? That's because we're very limited to design the
db un-like any other environment.
For ex: Can you do a parent child type updates and inserts in a single form?
Remedy can update one record at a time. It's hard to retrieve, update or insert
20 child records on a single button click or event. Go and ask Remedy tech or
remedy db designers! they say "NO". Why? because it's equipped with all tools.
But you can do this by manipulating lot of stuff on fly.



For example Remedy doesn't follow RDBMS normalization rulles at all.





Terrence J Hensley @LISTSERV.VISTAIT.COM> on 03/26/2001
11:40:17 AM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


**

Fair, hmmm, thats an interesting perception.

Remedy provides some degree of uniformity in creating fields, but this can
also be called an advantage. Ones development time can be significantly
reduced as the system defines specific fields automatically. All you have
to do is set the final parameters, not design the code that creates the
objects. There are other aspects as well, but no need togo there here.

And don't forget there are a lot of "Applications" created using VB. Ever
try fine tuning one! Or even tried modififying one to work with Remedy
where it didn't before?

Like Doug Tanner says in another email, yes Remedy does have available
pre-defined aplications, just like there are pre-defined VB applicaitons,
but with the Remedy Applications, you can readily get into them and make
changes as needed. Are the VB applications limited to the ones created by a
specific group of people? Of course not, neither is Remedy. Try thinking of
Remedy as another software development environment.

Remedy ARS should be compared to other development environments, like Vusal
Basic, C++ even, or Basic. They all make a computer do something
differently, but yet they are the same in that they all tell the computer at
the OS and hardware level pretty much the same thing.


Terrence J Hensley
Uni-Data Remedy Consultant

Check the possibilities:
http://www.sixfigureincome.com/?1239599

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> Sent: Monday, March 26, 2001 09:56
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> I don't think it's fair to compare Remedy with VB. Each one is in
> different
> worlds!
> Remedy is packaged apps and VB is development tool with which you
> can develop
> anything you want.
> If you want to develop with Remedy as development tool, you are
> limited to use
> Remedy concepts, which are very UN Object oriented and UN RDBMS
> concepts. The DB
> is designe to facilitate the Remedy concepts not RDBMS concepts.
> Remedy is good
> for what they meant Helpdesk, AM, CM ..
>
> VB is devlopement like any other GUI tool ( Powerbuilder, Delphi
> ). You design,
> build apps from scratch. You build the Database from scratch too.
> Again, they
> are completely different!
> Regards...
> Ravi Bommareddy
> Remedy Admn. & DBA
> JWT
>
>
>
>
>
> "Joel D. Sender" @LISTSERV.VISTAIT.COM> on 03/23/2001
> 03:07:36 PM
>
> Please respond to "Action Request System discussion list(ARSList)"
>
>
> Sent by: "Action Request System discussion list(ARSList)"
>
>
>
> To: ARSLIST@LISTSERV.VISTAIT.COM
> cc:
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> Jeneil,
> First, I agree with Will, he's covered the topic very well. In
> addition, one of
> the great strengths of AR System is that the application is stored as data
> in the SQL database. Unlike VB, which must have the client-side
> application
> program downloaded to each user's PC, AR System automatically downloads
> the latest version (if needed) when the user logs in. The cost
> and hassle of
> upgrading all those PCs - after even minor changes - pretty much justifies
> using
> (my favorite tool) AR System. Using ARWeb or RemedyWeb with
> 'public' licenses
> makes AR System as cost-effective, or better, than that product from the
> Redmond
> Monopoly.
>
> ... and that's my 2-cents ;-}
>
> Joel (NOT the moderator in this posting)
>
> At 12:37 AM 3/23/2001 -0600, William H. Du Chene wrote:
> >**
> >
> >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
> > >
> > >
> > >
> >
> > >
> >
> >
> >
> >
>
> Joel D. Sender
> ARSlist Moderator
> For Help with your subscription: JDSender@earthlink.net
> www.ARSlist.org
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ______
> _______________________
>
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org
>
> ______
> _______________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

Ravi wrote:

> Yes, in End user terms we can this, "Remedy is also a
> development tool"

I agree with you here. And many people would have difficulty developing in
Remedy, even though it seems really easy to us.

> But if you look in depth about all this programming and
> Database concepts, then
> you will see the difference.

I definitely agree with you here. I have been working with C for years and
am now learning C++, and I don't think Remedy is a comparable development
environment at all. It's not nearly as open-ended. But it does serve its
purpose and I wouldn't have a job without it.

I'm doing Remedy now in the interim until I am qualified for a real
development position. I certainly wouldn't call myself a developer based on
my Remedy development.

> strict standards and rules. Where as in Remedy, you develop
> your db along with
> your app. To use a table in remedy you have to create it
> through remedy. And you
> don't know what's going on in db when you create a table.

It's really hard to explain to anyone with regular database experience that
in Remedy, the table and the form are the same thing...that if I delete a
field from the form, it deletes all that data from the table.

> Remedy can update one record at a time. It's hard to
> retrieve, update or insert
> 20 child records on a single button click or event. Go and

What about 'Modify All' in the User Tool?

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

_____________________________

BRAVO ANN! I wonder if Boston Communications is aware that Shannon doesn't
know very much about remedy?

Art

-----Original Message-----
From: Ann Zbylut [mailto:ann.zbylut@GECTS.GE.COM]
Sent: Tuesday, March 27, 2001 2:49 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

I'm sorry, but I must take offense at your comment that you wouldn't
consider yourself a developer based on your Remedy development experience.

In my mind, a developer is someone who can create a product that matches
the needs of the end user of that product, no matter what 'language' it's
written in. And I know plenty of 'developers' that can't seem accomplish
that (no matter what language).

Remedy developers, in my experience, seem carry more of a load than the
typical programmer. There tends to be more customer contact and more of a
need for written, verbal, and people skills. Those, for many people, are
more difficult to master than programming skills.

And yes, I have experience in other languages, including VB. My choice?
Remedy. Where else can you develop an enterprise-wide product in the same
century as when the requirements are delivered. Those of us without
patience will choose Remedy...

I apologize for the rant, but I rarely feel this passionate about a subject
and had to get this one off my chest...


Humbly,

Ann Zbylut


On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis wrote:

>**
>
>Ravi wrote:
>
>> Yes, in End user terms we can this, "Remedy is also a
>> development tool"
>
>I agree with you here. And many people would have difficulty developing in
>Remedy, even though it seems really easy to us.
>
>> But if you look in depth about all this programming and
>> Database concepts, then
>> you will see the difference.
>
>I definitely agree with you here. I have been working with C for years and
>am now learning C++, and I don't think Remedy is a comparable development
>environment at all. It's not nearly as open-ended. But it does serve its
>purpose and I wouldn't have a job without it.
>
>I'm doing Remedy now in the interim until I am qualified for a real
>development position. I certainly wouldn't call myself a developer based
on
>my Remedy development.
>
>> strict standards and rules. Where as in Remedy, you develop
>> your db along with
>> your app. To use a table in remedy you have to create it
>> through remedy. And you
>> don't know what's going on in db when you create a table.
>
>It's really hard to explain to anyone with regular database experience that
>in Remedy, the table and the form are the same thing...that if I delete a
>field from the form, it deletes all that data from the table.
>
>> Remedy can update one record at a time. It's hard to
>> retrieve, update or insert
>> 20 child records on a single button click or event. Go and
>
>What about 'Modify All' in the User Tool?
>
>---
>Shannon B. Davis
>Remedy Systems Administrator
>Boston Communications Group, Inc.
>ph:(781) 904-5328
>sdavis@bcgi.net
>
>_______________
______________
>

>You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

> BRAVO ANN! I wonder if Boston Communications is aware that
> Shannon doesn't
> know very much about remedy?

Apparently some people's egos take up far too much of their time. I assume
that most people are on this list to learn more about their product, share
information, and help them get their jobs done - not read some silly
flamewar. So I have taken this discussion offline.

I really don't think I said anything that controversial. After acquiring a
bachelor's in Computer Science where we learned traditional programming
languages and used unix text editors to write our code, I disagree that
Remedy is an open-ended a development environment as, for example, C.

I don't need to defend my Remedy knowledge to anyone, least of all a 'me
too'-er.

-Nepenthe-

_____________________________

I missed Ann's original Post. Let me say to Ann..
Control Yourself Dear

:)ravi





Art Milbuta @LISTSERV.VISTAIT.COM> on 03/28/2001
10:00:03 AM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


**

BRAVO ANN! I wonder if Boston Communications is aware that Shannon doesn't
know very much about remedy?

Art

-----Original Message-----
From: Ann Zbylut [mailto:ann.zbylut@GECTS.GE.COM]
Sent: Tuesday, March 27, 2001 2:49 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

I'm sorry, but I must take offense at your comment that you wouldn't
consider yourself a developer based on your Remedy development experience.

In my mind, a developer is someone who can create a product that matches
the needs of the end user of that product, no matter what 'language' it's
written in. And I know plenty of 'developers' that can't seem accomplish
that (no matter what language).

Remedy developers, in my experience, seem carry more of a load than the
typical programmer. There tends to be more customer contact and more of a
need for written, verbal, and people skills. Those, for many people, are
more difficult to master than programming skills.

And yes, I have experience in other languages, including VB. My choice?
Remedy. Where else can you develop an enterprise-wide product in the same
century as when the requirements are delivered. Those of us without
patience will choose Remedy...

I apologize for the rant, but I rarely feel this passionate about a subject
and had to get this one off my chest...


Humbly,

Ann Zbylut


On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis wrote:

>**
>
>Ravi wrote:
>
>> Yes, in End user terms we can this, "Remedy is also a
>> development tool"
>
>I agree with you here. And many people would have difficulty developing in
>Remedy, even though it seems really easy to us.
>
>> But if you look in depth about all this programming and
>> Database concepts, then
>> you will see the difference.
>
>I definitely agree with you here. I have been working with C for years and
>am now learning C++, and I don't think Remedy is a comparable development
>environment at all. It's not nearly as open-ended. But it does serve its
>purpose and I wouldn't have a job without it.
>
>I'm doing Remedy now in the interim until I am qualified for a real
>development position. I certainly wouldn't call myself a developer based
on
>my Remedy development.
>
>> strict standards and rules. Where as in Remedy, you develop
>> your db along with
>> your app. To use a table in remedy you have to create it
>> through remedy. And you
>> don't know what's going on in db when you create a table.
>
>It's really hard to explain to anyone with regular database experience that
>in Remedy, the table and the form are the same thing...that if I delete a
>field from the form, it deletes all that data from the table.
>
>> Remedy can update one record at a time. It's hard to
>> retrieve, update or insert
>> 20 child records on a single button click or event. Go and
>
>What about 'Modify All' in the User Tool?
>
>---
>Shannon B. Davis
>Remedy Systems Administrator
>Boston Communications Group, Inc.
>ph:(781) 904-5328
>sdavis@bcgi.net
>
>_______________
______________
>

>You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

I have noticed that most developers (those with other language skills i.e.: C, C++ and even perl) have a very hard time understanding Remedy and working within the 4 items/modules. Yet and good Remedy designer (like some of the people on this this list) can write an application that rivals any C program.


rocky

Ann Zbylut wrote:


**

I'm sorry, but I must take offense at your comment that you wouldn't
consider yourself a developer based on your Remedy development experience.

In my mind, a developer is someone who can create a product that matches
the needs of the end user of that product, no matter what 'language' it's
written in. And I know plenty of 'developers' that can't seem accomplish
that (no matter what language).

Remedy developers, in my experience, seem carry more of a load than the
typical programmer. There tends to be more customer contact and more of a
need for written, verbal, and people skills. Those, for many people, are
more difficult to master than programming skills.

And yes, I have experience in other languages, including VB. My choice?
Remedy. Where else can you develop an enterprise-wide product in the same
century as when the!
requirements are delivered. Those of us without
patience will choose Remedy...

I apologize for the rant, but I rarely feel this passionate about a subject
and had to get this one off my chest...


Humbly,

Ann Zbylut


On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis wrote:


**

Ravi wrote:


Yes, in End user terms we can this, "Remedy is also a
development tool"

I agree with you here. And many people would have difficulty developing in
Remedy, even though it seems really easy to us.


But if you look in depth about all this programming and
Database concepts, then
you will see the difference.

I definitely agree with you here. I have been working with C for years and
am now learning C++, and I don't think Remedy is a comparable development
environment at all. It's not nearly as open-ended. But it does serve its
purpose and I wouldn't have a job without it.

I'm doing Remedy now in the interim until I am qualified for a real
development position. I certainly wouldn't call myself a developer based
!

on

my Remedy development.


strict standards and rules. Where as in Remedy, you develop
your db along with
your app. To use a table in remedy you have to create it
through remedy. And you
don't know what's going on in db when you create a table.

It's really hard to explain to anyone with regular database experience that
in Remedy, the table and the form are the same thing...that if I delete a
field from the form, it deletes all that data from the table.


Remedy can update one record at a time. It's hard to
retrieve, update or insert
20 child records on a single button click or event. Go and

What about 'Modify All' in the User Tool?

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-!
5328
sdavis@bcgi.net

_______________

______________





You may also control your subscription options, including UNSUBSCRIBE, at

www.ARSLIST.org

_____________________________

You may also control your subscription options, including UNSUBSCRIBE, at www.ARSLIST.org




--

Thanks,

Rocky

Rocky Rockwell

Texas Instruments

Plano, Texas

Email: rockwell@ti.com

Phone: 972-927-9237

I don't want to start an onlist flamewar, because this is certainly not
Remedy-related. I was going to take this offline - but wtf - I am also
offended. I just posted my opinions on a product - you have just insulted
my job performance. Besides, Art's mail just bounced - think he was worried that
I might stand up for myself and removed his account before he could receive my response?

Art seems to have missed the majority of my post where I defended Remedy as
a tool that serves its purpose very well, that I'm grateful to its
existence, and where I pointed out the existence of Modify All.

Boston Communications Group is very happy to have me, since I was the only
candidate in their three month search to have any Remedy Admin experience at
all, let alone the year of admin/development/troubleshooting that I do have.
I know that I'm not the consummate expert on the product - that's why I
joined this list - to learn more so that I can make our Remedy product work
even better.

I feel very sad to find that some members of this list can't have a
discussion on the pros and cons of Remedy without throwing punches at other
members.

-Shannon-
---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

> -----Original Message-----
> From: Art Milbuta [mailto:amilbuta@NET2PHONE.COM]
> Sent: Wednesday, March 28, 2001 9:00 AM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> BRAVO ANN! I wonder if Boston Communications is aware that
> Shannon doesn't
> know very much about remedy?
>
> Art
>

_____________________________

Rocky:
>I agree with most of what you say, however I prefer the word >designer. The
reason I say designer is that we are limited to >stay within 4 items (Active
Links, Filters, Escalation's and >Menus). Yes we can do more outside Remedy,
but we still have >to stay within the 4 items by designing how the
items/modules >work.

I really like how you put this. Designer is the perfect word. It does take
a unique skillset to do Remedy - I don't think it's the easiest thing in the
world, I don't think a monkey could do it. I tried to convey that in my
message. And I agree with Ann that Remedy does require a ton of people
skills, and you have to understand how the whole business process works, not
just the technology.

>I have noticed that most developers (those with other
>language skills i.e.: C, C++ and even perl) have a very hard >time
understanding Remedy and working within the 4
>items/modules. Yet and good Remedy designer (like some of the >people on
this this list) can write an application that
>rivals any C program.

And so much faster too, as Ann pointed out.

By the way, I'm very appreciative of Ann's thoughtful 'rant', where she
addressed the discussion with points about the product itself.

P.S. How do people here feel about HTML emails? On my other lists, we
strive to keep everything plain text so that all subscribers will be able to
read it. So when I reply to an HTML email, I have to reformat it into plain
text and add '>'s. Rocky's email was HTML formatted, so I have done that
here. If that isn't necessary, let me know and I'll reply in HTML as well.

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

_____________________________

I would much rather be called a programmer. Below is the definition for a programmer from the Webster dictionary. I sure wouldn't want my title to be " Sr. Remedy Designer". My 2 cents. Thanks All.


Main Entry: pro·gram·mer
Variant(s): also pro·gram·er /'prO-"gra-m&r, -gr&-/
Function: noun
Date: circa 1890
: one that programs: as a : a person who prepares and tests programs for devices (as computers) b : one that programs a mechanism c : one that prepares instructional or educational programs

-----Original Message-----
From: Shannon Davis [ mailto:sdavis@BCGI.NET]
Sent: Wednesday, March 28, 2001 10:36 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

Rocky:
>I agree with most of what you say, however I prefer the word >designer. The
reason I say designer is that we are limited to >stay within 4 items (Active
Links, Filters, Escalation's and >Menus). Yes we can do more outside Remedy,
but we still have >to stay within the 4 items by designing how the
items/modules >work.

I really like how you put this. Designer is the perfect word. It does take
a unique skillset to do Remedy - I don't think it's the easiest thing in the
world, I don't think a monkey could do it. I tried to convey that in my
message. And I agree with Ann that Remedy does require a ton of people
skills, and you have to understand how the whole business process works, not
just the technology.

>I have noticed that most developers (those with other
>language skills i.e.: C, C++ and even perl) have a very hard >time
understanding Remedy and working within the 4
>items/modules. Yet and good Remedy designer (like some of the >people on
this this list) can write an application that
>rivals any C program.

And so much faster too, as Ann pointed out.

By the way, I'm very appreciative of Ann's thoughtful 'rant', where she
addressed the discussion with points about the product itself.

P.S. How do people here feel about HTML emails? On my other lists, we
strive to keep everything plain text so that all subscribers will be able to
read it. So when I reply to an HTML email, I have to reformat it into plain
text and add '>'s. Rocky's email was HTML formatted, so I have done that
here. If that isn't necessary, let me know and I'll reply in HTML as well.

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

_____________________________

Remedy vs VB a few thoughts.....

"Sorta like arguing virture among whores?" - Hunter S. Thompson

"Kung Fu is better than Karate" - just about any Bruce Lee movie

"My dad can beat your dad" - a six year old fighting

"Visual Basic is far superior to Remedy" - the same six year old

"You know nothing, Remedy is much better then VB" - the other six year old
the first six year old is arguing with

Granted I'm new to the AR list, but name calling? I thought debate
was when opposing views are aired with each side discussing the features,
benefits, and virtues of thier view point. Guess not huh?

Tom

> -----Original Message-----
> From: Shannon Davis [SMTP:sdavis@BCGI.NET]
> Sent: Wednesday, March 28, 2001 10:11 AM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
> **
>
> > BRAVO ANN! I wonder if Boston Communications is aware that
> > Shannon doesn't
> > know very much about remedy?
>
> Apparently some people's egos take up far too much of their time. I
> assume
> that most people are on this list to learn more about their product, share
> information, and help them get their jobs done - not read some silly
> flamewar. So I have taken this discussion offline.
>
> I really don't think I said anything that controversial. After acquiring
> a
> bachelor's in Computer Science where we learned traditional programming
> languages and used unix text editors to write our code, I disagree that
> Remedy is an open-ended a development environment as, for example, C.
>
> I don't need to defend my Remedy knowledge to anyone, least of all a 'me
> too'-er.
>
> -Nepenthe-
>
> ______________
> _______________
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org

_____________________________

One of my Analytical Chemistry lesson tells me that the some facts are derived
from" Sampling"
So Let's give scintific sampling twist to this topic.

1. I believe 90% computing people doesn't know Remedy existence ( call your
non-remedy developers and ask them what remedy do)
2. About 99 % computing is done with non-remedy tools ( see the combined revenue
figures for all software tools companies, like Microsoft's SYBASE, SAP, SUN,
etc)
3. Remedy's usage other than service industry( HD, AM, CM, CRM) is almost none.
4. Market cap for all software tools companies cross trillion dollars, but
remedy's is ~ 300 mill

Help me out to give more #s, so we can get a conclusion

Ravi :)






Rocky Rockwell @LISTSERV.VISTAIT.COM> on 03/28/2001 11:14:53 AM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


I agree with most of what you say, however I prefer the word designer. The
reason I say designer is that we are limited to stay within 4 items (Active
Links, Filters, Escalation's and Menus). Yes we can do more outside Remedy, but
we still have to stay within the 4 items by designing how the 4 items/modules
work.

I have noticed that most developers (those with other language skills i.e.: C,
C++ and even perl) have a very hard time understanding Remedy and working within
the 4 items/modules. Yet and good Remedy designer (like some of the people on
this this list) can write an application that rivals any C program.


rocky

Ann Zbylut wrote:

**

I'm sorry, but I must take offense at your comment that you wouldn't
consider yourself a developer based on your Remedy development experience.

In my mind, a developer is someone who can create a product that matches
the needs of the end user of that product, no matter what 'language' it's
written in. And I know plenty of 'developers' that can't seem accomplish
that (no matter what language).

Remedy developers, in my experience, seem carry more of a load than the
typical programmer. There tends to be more customer contact and more of a
need for written, verbal, and people skills. Those, for many people, are
more difficult to master than programming skills.

And yes, I have experience in other languages, including VB. My choice?
Remedy. Where else can you develop an enterprise-wide product in the same
century as when the!
requirements are delivered. Those of us without
patience will choose Remedy...

I apologize for the rant, but I rarely feel this passionate about a subject
and had to get this one off my chest...


Humbly,

Ann Zbylut


On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis wrote:



**

Ravi wrote:



Yes, in End user terms we can this, "Remedy is also a
development tool"


I agree with you here. And many people would have difficulty developing in
Remedy, even though it seems really easy to us.



But if you look in depth about all this programming and
Database concepts, then
you will see the difference.


I definitely agree with you here. I have been working with C for years and
am now learning C++, and I don't think Remedy is a comparable development
environment at all. It's not nearly as open-ended. But it does serve its
purpose and I wouldn't have a job without it.

I'm doing Remedy now in the interim until I am qualified for a real
development position. I certainly wouldn't call myself a developer based


!

on


my Remedy development.



strict standards and rules. Where as in Remedy, you develop
your db along with
your app. To use a table in remedy you have to create it
through remedy. And you
don't know what's going on in db when you create a table.


It's really hard to explain to anyone with regular database experience that
in Remedy, the table and the form are the same thing...that if I delete a
field from the form, it deletes all that data from the table.



Remedy can update one record at a time. It's hard to
retrieve, update or insert
20 child records on a single button click or event. Go and


What about 'Modify All' in the User Tool?

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-!
5328
sdavis@bcgi.net

_______________


______________








You may also control your subscription options, including UNSUBSCRIBE, at


www.ARSLIST.org

_____________________________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org





--
Thanks,

Thanks,


Rocky


Rocky Rockwell

Texas Instruments

Plano, Texas

Email: rockwell@ti.com


Phone: 972-927-9237

_____________________________

Oh Boy





Ever Espana @LISTSERV.VISTAIT.COM> on
03/28/2001 11:52:19 AM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic




Shannon,

I would much rather be called a programmer. Below is the definition for a
programmer from the Webster dictionary.? I sure wouldn't want my title to be "
Sr. Remedy Designer". My 2 cents. Thanks All.

Main Entry: pro·gram·mer
Variant(s): also pro·gram·er /'prO-"gra-m&r, -gr&-/
Function: noun
Date: circa 1890
: one that programs: as a : a person who prepares and tests programs for devices
(as computers) b : one that programs a mechanism c : one that prepares
instructional or educational programs

-----Original Message-----
From: Shannon Davis [mailto:sdavis@BCGI.NET]
Sent: Wednesday, March 28, 2001 10:36 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic

**

Rocky:
>I agree with most of what you say, however I prefer the word >designer. The
reason I say designer is that we are limited to >stay within 4 items (Active
Links, Filters, Escalation's and >Menus). Yes we can do more outside Remedy,
but we still have >to stay within the 4 items by designing how the
items/modules >work.

I really like how you put this.? Designer is the perfect word.? It does take
a unique skillset to do Remedy - I don't think it's the easiest thing in the
world, I don't think a monkey could do it.? I tried to convey that in my
message.? And I agree with Ann that Remedy does require a ton of people
skills, and you have to understand how the whole business process works, not
just the technology.

>I have noticed that most developers (those with other
>language skills i.e.: C, C++ and even perl) have a very hard >time
understanding Remedy and working within the 4
>items/modules. Yet and good Remedy designer (like some of the >people on
this this list) can write an application that
>rivals any C program.

And so much faster too, as Ann pointed out.

By the way, I'm very appreciative of Ann's thoughtful 'rant', where she
addressed the discussion with points about the product itself.

P.S. How do people here feel about HTML emails?? On my other lists, we
strive to keep everything plain text so that all subscribers will be able to
read it.? So when I reply to an HTML email, I have to reformat it into plain
text and add '>'s.? Rocky's email was HTML formatted, so I have done that
here.? If that isn't necessary, let me know and I'll reply in HTML as well.

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org



N?
I@R 
??azg???.n?????h?-??+-??+-j+\?(??[(r??rb???m?????[?x5%
H$HF?E"?:+

I HAVE COME TO A CONCLUSION!!!!

No matter what my title and experience, I have a ton of Remedy work
assigned to me and a heavier ton of learning ( by example, referral, THIS
LIST, trial and error, etc. needed to accomplish the assignment.

I am sure there is plenty of room for all of us in the Remedy world, and
the Programming world in general.

Let's all rest our egos and be thankful that we have each other - it's a
jungle out there!

-Lori
(a Newbie, and proud of it)

_____________________________

Dito Lori

-----Original Message-----
From: Lori Gumbiner [mailto:Lori.Gumbiner@WALGREENS.COM]
Sent: Wednesday, March 28, 2001 10:19 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

I HAVE COME TO A CONCLUSION!!!!

No matter what my title and experience, I have a ton of Remedy work
assigned to me and a heavier ton of learning ( by example, referral, THIS
LIST, trial and error, etc. needed to accomplish the assignment.

I am sure there is plenty of room for all of us in the Remedy world, and
the Programming world in general.

Let's all rest our egos and be thankful that we have each other - it's a
jungle out there!

-Lori
(a Newbie, and proud of it)

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

Shannon,

I apologize wholeheartedly for what has occurred as a result of my e-mail.
When I said in my message that I took offense at your comment, it should
have said that I simply disagree.

Hopefully you were not personally upset by what I wrote. It was not
intended that way...


Even more humbly,

Ann Zbylut

_____________________________

Kudos Lori!

and let's not forget what a pain in the but it is deleting all the
flaming email
I'm new to it too, I read the posts to gain insights and ideas, not argue.

Best Regards,

Thomas Altamore
Remedy System Admin/Developer
Operations Department
NetSat Express Inc.
45 Oser Ave.
Hauppauge, NY 11788
Tel: 631-231-4422 Ext.1306
E-mail: taltamore@netsatx.net




> -----Original Message-----
> From: Lori Gumbiner [SMTP:Lori.Gumbiner@WALGREENS.COM]
> Sent: Wednesday, March 28, 2001 11:19 AM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
> **
>
> I HAVE COME TO A CONCLUSION!!!!
>
> No matter what my title and experience, I have a ton of Remedy work
> assigned to me and a heavier ton of learning ( by example, referral, THIS
> LIST, trial and error, etc. needed to accomplish the assignment.
>
> I am sure there is plenty of room for all of us in the Remedy world, and
> the Programming world in general.
>
> Let's all rest our egos and be thankful that we have each other - it's a
> jungle out there!
>
> -Lori
> (a Newbie, and proud of it)
>
> ______________
> _______________
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org

_____________________________

I don't have any numbers to add, but I think you have struck upon a point
without sayig. Remedy came to be with a niche in mind, and that was the
services industry. As a result Remedy has proven to be very strong in that
niche. Historically, if I am not mistaken, those who leave their niche
usually find it a long road to haul to broaden their horizons. That is not
to say that Remedy can't or shouldn't.

A case in point from the archives,

A Commodore computer was a game machine only - not for me - I used it like
my current respectable system and seldomly used it for games. In fact I used
it in a small business for a few years.

Terrence J Hensley
Uni-Data Remedy Consultant

Check the possibilities:
http://www.sixfigureincome.com/?1239599

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> Sent: Wednesday, March 28, 2001 10:40
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> One of my Analytical Chemistry lesson tells me that the some
> facts are derived
> from" Sampling"
> So Let's give scintific sampling twist to this topic.
>
> 1. I believe 90% computing people doesn't know Remedy existence

> call your
> non-remedy developers and ask them what remedy do)
> 2. About 99 % computing is done with non-remedy tools ( see the
> combined revenue
> figures for all software tools companies, like Microsoft's
> SYBASE, SAP, SUN,
> etc)
> 3. Remedy's usage other than service industry( HD, AM, CM, CRM)
> is almost none.
> 4. Market cap for all software tools companies cross trillion dollars, but
> remedy's is ~ 300 mill
>
> Help me out to give more #s, so we can get a conclusion
>
> Ravi :)
>
>
>
>
>
>
> Rocky Rockwell @LISTSERV.VISTAIT.COM> on
> 03/28/2001 11:14:53 AM
>
> Please respond to "Action Request System discussion list(ARSList)"
>
>
> Sent by: "Action Request System discussion list(ARSList)"
>
>
>
> To: ARSLIST@LISTSERV.VISTAIT.COM
> cc:
> Subject: Re: Remedy vs. Visual Basic
>
>
> I agree with most of what you say, however I prefer the word designer. The
> reason I say designer is that we are limited to stay within 4
> items (Active
> Links, Filters, Escalation's and Menus). Yes we can do more
> outside Remedy, but
> we still have to stay within the 4 items by designing how the 4
> items/modules
> work.
>
> I have noticed that most developers (those with other language
> skills i.e.: C,
> C++ and even perl) have a very hard time understanding Remedy and
> working within
> the 4 items/modules. Yet and good Remedy designer (like some of
> the people on
> this this list) can write an application that rivals any C program.
>
>
> rocky
>
> Ann Zbylut wrote:
>
> **
>
> I'm sorry, but I must take offense at your comment that you wouldn't
> consider yourself a developer based on your Remedy development experience.
>
> In my mind, a developer is someone who can create a product that matches
> the needs of the end user of that product, no matter what 'language' it's
> written in. And I know plenty of 'developers' that can't seem accomplish
> that (no matter what language).
>
> Remedy developers, in my experience, seem carry more of a load than the
> typical programmer. There tends to be more customer contact and more of a
> need for written, verbal, and people skills. Those, for many people, are
> more difficult to master than programming skills.
>
> And yes, I have experience in other languages, including VB. My choice?
> Remedy. Where else can you develop an enterprise-wide product in the same
> century as when the!
> requirements are delivered. Those of us without
> patience will choose Remedy...
>
> I apologize for the rant, but I rarely feel this passionate about
> a subject
> and had to get this one off my chest...
>
>
> Humbly,
>
> Ann Zbylut
>
>
> On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis wrote:
>
>
>
> **
>
> Ravi wrote:
>
>
>
> Yes, in End user terms we can this, "Remedy is also a
> development tool"
>
>
> I agree with you here. And many people would have difficulty
> developing in
> Remedy, even though it seems really easy to us.
>
>
>
> But if you look in depth about all this programming and
> Database concepts, then
> you will see the difference.
>
>
> I definitely agree with you here. I have been working with C for
> years and
> am now learning C++, and I don't think Remedy is a comparable development
> environment at all. It's not nearly as open-ended. But it does serve its
> purpose and I wouldn't have a job without it.
>
> I'm doing Remedy now in the interim until I am qualified for a real
> development position. I certainly wouldn't call myself a developer based
>
>
> !
>
> on
>
>
> my Remedy development.
>
>
>
> strict standards and rules. Where as in Remedy, you develop
> your db along with
> your app. To use a table in remedy you have to create it
> through remedy. And you
> don't know what's going on in db when you create a table.
>
>
> It's really hard to explain to anyone with regular database
> experience that
> in Remedy, the table and the form are the same thing...that if I delete a
> field from the form, it deletes all that data from the table.
>
>
>
> Remedy can update one record at a time. It's hard to
> retrieve, update or insert
> 20 child records on a single button click or event. Go and
>
>
> What about 'Modify All' in the User Tool?
>
> ---
> Shannon B. Davis
> Remedy Systems Administrator
> Boston Communications Group, Inc.
> ph:(781) 904-!
> 5328
> sdavis@bcgi.net
>
> ______
> _________
>
>
> ______________
>
>
>
>
>
>
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
>
>
> www.ARSLIST.org
>
> ______
> _______________________
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org
>
>
>
>
>
> --
> Thanks,
>
> Thanks,
>
>
> Rocky
>
>
> Rocky Rockwell
>
> Texas Instruments
>
> Plano, Texas
>
> Email: rockwell@ti.com
>
>
> Phone: 972-927-9237
>
> ______
> _______________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

_____________________________

Hi Ann,

I too apologize if you were offended by my post, I just wanted to
make the point that we were getting off track from the purpose of this list.
On the bright side... at least a war didn't break out between the Remedy
Liberation Jihad and the Fundamentalist Visual Basic Front .
One observation I can share with you though.... Remedy Admins and
Developers are greatly under appreciated.

Best Regards,
Thomas Altamore
Remedy System Admin/Developer
Operations Department
NetSat Express Inc.
45 Oser Ave.
Hauppauge, NY 11788
Tel: 631-231-4422 Ext.1306
E-mail: taltamore@netsatx.net




> -----Original Message-----
> From: Ann Zbylut [SMTP:ann.zbylut@GECTS.GE.COM]
> Sent: Wednesday, March 28, 2001 11:24 AM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
> **
>
> Shannon,
>
> I apologize wholeheartedly for what has occurred as a result of my e-mail.
> When I said in my message that I took offense at your comment, it should
> have said that I simply disagree.
>
> Hopefully you were not personally upset by what I wrote. It was not
> intended that way...
>
>
> Even more humbly,
>
> Ann Zbylut
>
> ______________
> _______________
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org

_____________________________

I would have to disagree with this, Using the run process from within
Remedy, one can use externally developed tools to do many things. I use Win
Batch to do several things.

Eric

-----Original Message-----
From: Rocky Rockwell [mailto:rockwell@TI.COM]
Sent: Wednesday, March 28, 2001 9:15 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


I agree with most of what you say, however I prefer the word designer. The
reason I say designer is that we are limited to stay within 4 items (Active
Links, Filters, Escalation's and Menus). Yes we can do more outside Remedy,
but we still have to stay within the 4 items by designing how the 4
items/modules work.

I have noticed that most developers (those with other language skills i.e.:
C, C++ and even perl) have a very hard time understanding Remedy and working
within the 4 items/modules. Yet and good Remedy designer (like some of the
people on this this list) can write an application that rivals any C
program.


rocky

Ann Zbylut wrote:


**

I'm sorry, but I must take offense at your comment that you wouldn't
consider yourself a developer based on your Remedy development experience.

In my mind, a developer is someone who can create a product that matches
the needs of the end user of that product, no matter what 'language' it's
written in. And I know plenty of 'developers' that can't seem accomplish
that (no matter what language).

Remedy developers, in my experience, seem carry more of a load than the
typical programmer. There tends to be more customer contact and more of a
need for written, verbal, and people skills. Those, for many people, are
more difficult to master than programming skills.

And yes, I have experience in other languages, including VB. My choice?
Remedy. Where else can you develop an enterprise-wide product in the same
century as when the!

requirements are delivered. Those of us without
patience will choose Remedy...

I apologize for the rant, but I rarely feel this passionate about a subject
and had to get this one off my chest...


Humbly,

Ann Zbylut


On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis
wrote:


**

Ravi wrote:


Yes, in End user terms we can this, "Remedy is also a
development tool"

I agree with you here. And many people would have difficulty developing in
Remedy, even though it seems really easy to us.


But if you look in depth about all this programming and
Database concepts, then
you will see the difference.

I definitely agree with you here. I have been working with C for years and
am now learning C++, and I don't think Remedy is a comparable development
environment at all. It's not nearly as open-ended. But it does serve its
purpose and I wouldn't have a job without it.

I'm doing Remedy now in the interim until I am qualified for a real
development position. I certainly wouldn't call myself a developer based
!

on

my Remedy development.


strict standards and rules. Where as in Remedy, you develop
your db along with
your app. To use a table in remedy you have to create it
through remedy. And you
don't know what's going on in db when you create a table.

It's really hard to explain to anyone with regular database experience that
in Remedy, the table and the form are the same thing...that if I delete a
field from the form, it deletes all that data from the table.


Remedy can update one record at a time. It's hard to
retrieve, update or insert
20 child records on a single button click or event. Go and

What about 'Modify All' in the User Tool?

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-!

5328
sdavis@bcgi.net

_______________

______________





You may also control your subscription options, including UNSUBSCRIBE, at

www.ARSLIST.org

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org




--

Thanks,

Rocky

Rocky Rockwell

Texas Instruments

Plano, Texas

Email: rockwell@ti.com

Phone: 972-927-9237

_____________________________

Terrence,
"Remedy came to be with a niche in mind"
I just wanna refresh the topic agian, the discussion is not Remedy's niche
market, we're talking about Remedy vs. VB and the question is: does Remedy has
full strength to be a player in the traditional c.s. programming tools arena?

I totally agree with your statement about Remedy's dominence in it's Niche.
I hope you can see the meaning of my numbers now!

Regards...
Ravi








Terrence J Hensley @LISTSERV.VISTAIT.COM> on 03/28/2001
01:37:13 PM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:
Subject: Re: Remedy vs. Visual Basic


**

I don't have any numbers to add, but I think you have struck upon a point
without sayig. Remedy came to be with a niche in mind, and that was the
services industry. As a result Remedy has proven to be very strong in that
niche. Historically, if I am not mistaken, those who leave their niche
usually find it a long road to haul to broaden their horizons. That is not
to say that Remedy can't or shouldn't.

A case in point from the archives,

A Commodore computer was a game machine only - not for me - I used it like
my current respectable system and seldomly used it for games. In fact I used
it in a small business for a few years.

Terrence J Hensley
Uni-Data Remedy Consultant

Check the possibilities:
http://www.sixfigureincome.com/?1239599

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> Sent: Wednesday, March 28, 2001 10:40
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> One of my Analytical Chemistry lesson tells me that the some
> facts are derived
> from" Sampling"
> So Let's give scintific sampling twist to this topic.
>
> 1. I believe 90% computing people doesn't know Remedy existence

> call your
> non-remedy developers and ask them what remedy do)
> 2. About 99 % computing is done with non-remedy tools ( see the
> combined revenue
> figures for all software tools companies, like Microsoft's
> SYBASE, SAP, SUN,
> etc)
> 3. Remedy's usage other than service industry( HD, AM, CM, CRM)
> is almost none.
> 4. Market cap for all software tools companies cross trillion dollars, but
> remedy's is ~ 300 mill
>
> Help me out to give more #s, so we can get a conclusion
>
> Ravi :)
>
>
>
>
>
>
> Rocky Rockwell @LISTSERV.VISTAIT.COM> on
> 03/28/2001 11:14:53 AM
>
> Please respond to "Action Request System discussion list(ARSList)"
>
>
> Sent by: "Action Request System discussion list(ARSList)"
>
>
>
> To: ARSLIST@LISTSERV.VISTAIT.COM
> cc:
> Subject: Re: Remedy vs. Visual Basic
>
>
> I agree with most of what you say, however I prefer the word designer. The
> reason I say designer is that we are limited to stay within 4
> items (Active
> Links, Filters, Escalation's and Menus). Yes we can do more
> outside Remedy, but
> we still have to stay within the 4 items by designing how the 4
> items/modules
> work.
>
> I have noticed that most developers (those with other language
> skills i.e.: C,
> C++ and even perl) have a very hard time understanding Remedy and
> working within
> the 4 items/modules. Yet and good Remedy designer (like some of
> the people on
> this this list) can write an application that rivals any C program.
>
>
> rocky
>
> Ann Zbylut wrote:
>
> **
>
> I'm sorry, but I must take offense at your comment that you wouldn't
> consider yourself a developer based on your Remedy development experience.
>
> In my mind, a developer is someone who can create a product that matches
> the needs of the end user of that product, no matter what 'language' it's
> written in. And I know plenty of 'developers' that can't seem accomplish
> that (no matter what language).
>
> Remedy developers, in my experience, seem carry more of a load than the
> typical programmer. There tends to be more customer contact and more of a
> need for written, verbal, and people skills. Those, for many people, are
> more difficult to master than programming skills.
>
> And yes, I have experience in other languages, including VB. My choice?
> Remedy. Where else can you develop an enterprise-wide product in the same
> century as when the!
> requirements are delivered. Those of us without
> patience will choose Remedy...
>
> I apologize for the rant, but I rarely feel this passionate about
> a subject
> and had to get this one off my chest...
>
>
> Humbly,
>
> Ann Zbylut
>
>
> On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis wrote:
>
>
>
> **
>
> Ravi wrote:
>
>
>
> Yes, in End user terms we can this, "Remedy is also a
> development tool"
>
>
> I agree with you here. And many people would have difficulty
> developing in
> Remedy, even though it seems really easy to us.
>
>
>
> But if you look in depth about all this programming and
> Database concepts, then
> you will see the difference.
>
>
> I definitely agree with you here. I have been working with C for
> years and
> am now learning C++, and I don't think Remedy is a comparable development
> environment at all. It's not nearly as open-ended. But it does serve its
> purpose and I wouldn't have a job without it.
>
> I'm doing Remedy now in the interim until I am qualified for a real
> development position. I certainly wouldn't call myself a developer based
>
>
> !
>
> on
>
>
> my Remedy development.
>
>
>
> strict standards and rules. Where as in Remedy, you develop
> your db along with
> your app. To use a table in remedy you have to create it
> through remedy. And you
> don't know what's going on in db when you create a table.
>
>
> It's really hard to explain to anyone with regular database
> experience that
> in Remedy, the table and the form are the same thing...that if I delete a
> field from the form, it deletes all that data from the table.
>
>
>
> Remedy can update one record at a time. It's hard to
> retrieve, update or insert
> 20 child records on a single button click or event. Go and
>
>
> What about 'Modify All' in the User Tool?
>
> ---
> Shannon B. Davis
> Remedy Systems Administrator
> Boston Communications Group, Inc.
> ph:(781) 904-!
> 5328
> sdavis@bcgi.net
>
> ______
> _________
>
>
> ______________
>
>
>
>
>
>
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
>
>
> www.ARSLIST.org
>
> ______
> _______________________
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org
>
>
>
>
>
> --
> Thanks,
>
> Thanks,
>
>
> Rocky
>
>
> Rocky Rockwell
>
> Texas Instruments
>
> Plano, Texas
>
> Email: rockwell@ti.com
>
>
> Phone: 972-927-9237
>
> ______
> _______________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

Terrence wrote:
> niche. Historically, if I am not mistaken, those who leave
>their niche
> usually find it a long road to haul to broaden their
> horizons. That is not
> to say that Remedy can't or shouldn't.

So what do you guys do to keep in touch with the rest of the world or ensure
that you'll have jobs even if Remedy goes away? Personally, I am trying to
bone up on unix skills and teaching myself C++ and PERL. And I know I could
fall back on NT admin or desktop support if the economy falls apart.

One of my worries in taking this job was that I'd be consigned to Remedy
development for the rest of my life. I like it a lot, but my dream is to
work with ... programming language? (I don't want to offend anyone this
time). I'm really hoping that I can use this job to improve my development
skills (at least in design & mentality) while I get better at coding. You
see, when I graduated from college, I made the mistake of going into the
administrative side of computers (networking etc) instead of programming,
and only later realized that I am more fulfilled by the latter than the
former.

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

_____________________________

Well said ... no apologies necessary.

--
Michael Ross
MGR Consulting Services
mross@connix.com
(203) 287-8917

Ann Zbylut wrote:

> **
>
> I'm sorry, but I must take offense at your comment that you wouldn't
> consider yourself a developer based on your Remedy development experience.
>
> In my mind, a developer is someone who can create a product that matches
> the needs of the end user of that product, no matter what 'language' it's
> written in. And I know plenty of 'developers' that can't seem accomplish
> that (no matter what language).
>
> Remedy developers, in my experience, seem carry more of a load than the
> typical programmer. There tends to be more customer contact and more of a
> need for written, verbal, and people skills. Those, for many people, are
> more difficult to master than programming skills.
>
> And yes, I have experience in other languages, including VB. My choice?
> Remedy. Where else can you develop an enterprise-wide product in the same
> century as when the requirements are delivered. Those of us without
> patience will choose Remedy...
>
> I apologize for the rant, but I rarely feel this passionate about a subject
> and had to get this one off my chest...
>
> Humbly,
>
> Ann Zbylut

_____________________________

One of the things that I have always like about being a Remedy Admin is the
oportunity to do several diffterent
things. As a Remedy Admin I have been:
Remedy Admin, Web Admin & Developer (cgi),
Remedy Support Programs Developer in both Unix and Windows,
Database Admin, Unix Admin.




Shannon Davis @LISTSERV.VISTAIT.COM> on 03/28/2001
10:15:53 AM

Please respond to "Action Request System discussion list(ARSList)"


Sent by: "Action Request System discussion list(ARSList)"



To: ARSLIST@LISTSERV.VISTAIT.COM
cc:

Subject: Re: Remedy vs. Visual Basic


**

Terrence wrote:
> niche. Historically, if I am not mistaken, those who leave
>their niche
> usually find it a long road to haul to broaden their
> horizons. That is not
> to say that Remedy can't or shouldn't.

So what do you guys do to keep in touch with the rest of the world or
ensure
that you'll have jobs even if Remedy goes away? Personally, I am trying to
bone up on unix skills and teaching myself C++ and PERL. And I know I
could
fall back on NT admin or desktop support if the economy falls apart.

One of my worries in taking this job was that I'd be consigned to Remedy
development for the rest of my life. I like it a lot, but my dream is to
work with ... programming language? (I don't want to offend anyone this
time). I'm really hoping that I can use this job to improve my development
skills (at least in design & mentality) while I get better at coding. You
see, when I graduated from college, I made the mistake of going into the
administrative side of computers (networking etc) instead of programming,
and only later realized that I am more fulfilled by the latter than the
former.

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

That is one plus for the VB argument is longevity. C & C++ have survived a long
time and still create jobs as does VB. Remedy is flexible and I hope it is
around for a while, but it is more likely to dissolve before a prog language. A
good experience to take from Remedy is Project planning experience, gap
analysis, inplementation, design, requirements gathering etc. You can take those
abilities and apply them to pretty much anything. It is always a good idea to
follow Remedy competing products as well, just in case.



|--------+----------------------->
| | sdavis@bcgi.n|
| | et |
| | |
| | 03/28/01 |
| | 10:15 AM |
| | Please |
| | respond to |
| | ARSLIST |
| | |
|--------+----------------------->
>----------------------------------------------------------------------------|
| |
| To: ARSLIST@listserv.vistait.com |
| cc: (bcc: Ron Pierce/Contractor/Enron Communications) |
| Subject: Re: Remedy vs. Visual Basic |
>----------------------------------------------------------------------------|



**

Terrence wrote:
> niche. Historically, if I am not mistaken, those who leave
>their niche
> usually find it a long road to haul to broaden their
> horizons. That is not
> to say that Remedy can't or shouldn't.

So what do you guys do to keep in touch with the rest of the world or ensure
that you'll have jobs even if Remedy goes away? Personally, I am trying to
bone up on unix skills and teaching myself C++ and PERL. And I know I could
fall back on NT admin or desktop support if the economy falls apart.

One of my worries in taking this job was that I'd be consigned to Remedy
development for the rest of my life. I like it a lot, but my dream is to
work with ... programming language? (I don't want to offend anyone this
time). I'm really hoping that I can use this job to improve my development
skills (at least in design & mentality) while I get better at coding. You
see, when I graduated from college, I made the mistake of going into the
administrative side of computers (networking etc) instead of programming,
and only later realized that I am more fulfilled by the latter than the
former.

---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

Immediately Sis and Desist..
Stop this GARB NOW !


Customer Support Program Manager/Remedy Development Manager
Zandi Patrick S TSgt AFRL/IFOSS WP 315-330-3911 Fax 315-330-3314
Air Force Rome Research Laboratory, 525 Brooks Ave Rome NY, 13440,
Way to Go Remedy ~~~>
(NOT VB !)

_____________________________

Try me again and see if my e-mail 'bounces'

PS If you can't take the heat, don't start a fire.

Art Milbuta
amilbuta@net2phone.com
973-412-3622

-----Original Message-----
From: Shannon Davis [mailto:sdavis@BCGI.NET]
Sent: Wednesday, March 28, 2001 10:17 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

I don't want to start an onlist flamewar, because this is certainly not
Remedy-related. I was going to take this offline - but wtf - I am also
offended. I just posted my opinions on a product - you have just insulted
my job performance. Besides, Art's mail just bounced - think he was
worried that
I might stand up for myself and removed his account before he could receive
my response?

Art seems to have missed the majority of my post where I defended Remedy as
a tool that serves its purpose very well, that I'm grateful to its
existence, and where I pointed out the existence of Modify All.

Boston Communications Group is very happy to have me, since I was the only
candidate in their three month search to have any Remedy Admin experience at
all, let alone the year of admin/development/troubleshooting that I do have.
I know that I'm not the consummate expert on the product - that's why I
joined this list - to learn more so that I can make our Remedy product work
even better.

I feel very sad to find that some members of this list can't have a
discussion on the pros and cons of Remedy without throwing punches at other
members.

-Shannon-
---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

> -----Original Message-----
> From: Art Milbuta [mailto:amilbuta@NET2PHONE.COM]
> Sent: Wednesday, March 28, 2001 9:00 AM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> BRAVO ANN! I wonder if Boston Communications is aware that
> Shannon doesn't
> know very much about remedy?
>
> Art
>

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

Certainly, and I agree with the numbers idea. I just wanted to add what I
believe what those numbers will probably really show.

And now, as Patrick Zandi as asked, I will cease and desist from this
interesting but probably not so appropriate discussion on the ARS List.

Terrence J Hensley
Uni-Data Remedy Consultant

Check the possibilities:
http://www.sixfigureincome.com/?1239599

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> Sent: Wednesday, March 28, 2001 12:55
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> Terrence,
> "Remedy came to be with a niche in mind"
> I just wanna refresh the topic agian, the discussion is not Remedy's niche
> market, we're talking about Remedy vs. VB and the question is:
> does Remedy has
> full strength to be a player in the traditional c.s. programming
> tools arena?
>
> I totally agree with your statement about Remedy's dominence in
> it's Niche.
> I hope you can see the meaning of my numbers now!
>
> Regards...
> Ravi
>
>
>
>
>
>
>
>
> Terrence J Hensley @LISTSERV.VISTAIT.COM>
> on 03/28/2001
> 01:37:13 PM
>
> Please respond to "Action Request System discussion list(ARSList)"
>
>
> Sent by: "Action Request System discussion list(ARSList)"
>
>
>
> To: ARSLIST@LISTSERV.VISTAIT.COM
> cc:
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> I don't have any numbers to add, but I think you have struck upon a point
> without sayig. Remedy came to be with a niche in mind, and that was the
> services industry. As a result Remedy has proven to be very strong in that
> niche. Historically, if I am not mistaken, those who leave their niche
> usually find it a long road to haul to broaden their horizons. That is not
> to say that Remedy can't or shouldn't.
>
> A case in point from the archives,
>
> A Commodore computer was a game machine only - not for me - I used it like
> my current respectable system and seldomly used it for games. In
> fact I used
> it in a small business for a few years.
>
> Terrence J Hensley
> Uni-Data Remedy Consultant
>
> Check the possibilities:
> http://www.sixfigureincome.com/?1239599
>
> > -----Original Message-----
> > From: Action Request System discussion list(ARSList)
> > [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> > Sent: Wednesday, March 28, 2001 10:40
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > Subject: Re: Remedy vs. Visual Basic
> >
> >
> > **
> >
> > One of my Analytical Chemistry lesson tells me that the some
> > facts are derived
> > from" Sampling"
> > So Let's give scintific sampling twist to this topic.
> >
> > 1. I believe 90% computing people doesn't know Remedy existence
>
> > call your
> > non-remedy developers and ask them what remedy do)
> > 2. About 99 % computing is done with non-remedy tools ( see the
> > combined revenue
> > figures for all software tools companies, like Microsoft's
> > SYBASE, SAP, SUN,
> > etc)
> > 3. Remedy's usage other than service industry( HD, AM, CM, CRM)
> > is almost none.
> > 4. Market cap for all software tools companies cross trillion
> dollars, but
> > remedy's is ~ 300 mill
> >
> > Help me out to give more #s, so we can get a conclusion
> >
> > Ravi :)
> >
> >
> >
> >
> >
> >
> > Rocky Rockwell @LISTSERV.VISTAIT.COM> on
> > 03/28/2001 11:14:53 AM
> >
> > Please respond to "Action Request System discussion list(ARSList)"
> >
> >
> > Sent by: "Action Request System discussion list(ARSList)"
> >
> >
> >
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > cc:
> > Subject: Re: Remedy vs. Visual Basic
> >
> >
> > I agree with most of what you say, however I prefer the word
> designer. The
> > reason I say designer is that we are limited to stay within 4
> > items (Active
> > Links, Filters, Escalation's and Menus). Yes we can do more
> > outside Remedy, but
> > we still have to stay within the 4 items by designing how the 4
> > items/modules
> > work.
> >
> > I have noticed that most developers (those with other language
> > skills i.e.: C,
> > C++ and even perl) have a very hard time understanding Remedy and
> > working within
> > the 4 items/modules. Yet and good Remedy designer (like some of
> > the people on
> > this this list) can write an application that rivals any C program.
> >
> >
> > rocky
> >
> > Ann Zbylut wrote:
> >
> > **
> >
> > I'm sorry, but I must take offense at your comment that you wouldn't
> > consider yourself a developer based on your Remedy development
> experience.
> >
> > In my mind, a developer is someone who can create a product that matches
> > the needs of the end user of that product, no matter what
> 'language' it's
> > written in. And I know plenty of 'developers' that can't seem
> accomplish
> > that (no matter what language).
> >
> > Remedy developers, in my experience, seem carry more of a load than the
> > typical programmer. There tends to be more customer contact
> and more of a
> > need for written, verbal, and people skills. Those, for many
> people, are
> > more difficult to master than programming skills.
> >
> > And yes, I have experience in other languages, including VB. My choice?
> > Remedy. Where else can you develop an enterprise-wide product
> in the same
> > century as when the!
> > requirements are delivered. Those of us without
> > patience will choose Remedy...
> >
> > I apologize for the rant, but I rarely feel this passionate about
> > a subject
> > and had to get this one off my chest...
> >
> >
> > Humbly,
> >
> > Ann Zbylut
> >
> >
> > On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis
> wrote:
> >
> >
> >
> > **
> >
> > Ravi wrote:
> >
> >
> >
> > Yes, in End user terms we can this, "Remedy is also a
> > development tool"
> >
> >
> > I agree with you here. And many people would have difficulty
> > developing in
> > Remedy, even though it seems really easy to us.
> >
> >
> >
> > But if you look in depth about all this programming and
> > Database concepts, then
> > you will see the difference.
> >
> >
> > I definitely agree with you here. I have been working with C for
> > years and
> > am now learning C++, and I don't think Remedy is a comparable
> development
> > environment at all. It's not nearly as open-ended. But it
> does serve its
> > purpose and I wouldn't have a job without it.
> >
> > I'm doing Remedy now in the interim until I am qualified for a real
> > development position. I certainly wouldn't call myself a
> developer based
> >
> >
> > !
> >
> > on
> >
> >
> > my Remedy development.
> >
> >
> >
> > strict standards and rules. Where as in Remedy, you develop
> > your db along with
> > your app. To use a table in remedy you have to create it
> > through remedy. And you
> > don't know what's going on in db when you create a table.
> >
> >
> > It's really hard to explain to anyone with regular database
> > experience that
> > in Remedy, the table and the form are the same thing...that if
> I delete a
> > field from the form, it deletes all that data from the table.
> >
> >
> >
> > Remedy can update one record at a time. It's hard to
> > retrieve, update or insert
> > 20 child records on a single button click or event. Go and
> >
> >
> > What about 'Modify All' in the User Tool?
> >
> > ---
> > Shannon B. Davis
> > Remedy Systems Administrator
> > Boston Communications Group, Inc.
> > ph:(781) 904-!
> > 5328
> > sdavis@bcgi.net
> >
> > ______
> > _________
> >
> >
> > ______________
> >
> >
> >
> >
> >
> >
> >
> >
> > You may also control your subscription options, including
> UNSUBSCRIBE, at
> >
> >
> > www.ARSLIST.org
> >
> > ______
> > _______________________
> >
> >
> > You may also control your subscription options, including
> UNSUBSCRIBE, at
> > www.ARSLIST.org
> >
> >
> >
> >
> >
> > --
> > Thanks,
> >
> > Thanks,
> >
> >
> > Rocky
> >
> >
> > Rocky Rockwell
> >
> > Texas Instruments
> >
> > Plano, Texas
> >
> > Email: rockwell@ti.com
> >
> >
> > Phone: 972-927-9237
> >
> > ______
> > _______________________
> >
> >
> > You may also control your subscription options, including
> > UNSUBSCRIBE, at www.ARSLIST.org
> >
>
> ______
> _______________________
>
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org
>
> ______
> _______________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

_____________________________

Am I going to have to put you two in 'time out'!!! That's my typical response
when my niece and nephew act this way to each other.

Don't make me pull this car over...

In all seriousness, we can all get along better than this. It seems like every
6-9 months we have one of these episodes where a few people get overwrought by
something someone else says. There's no need or place for insults and berating
others especially in a public forum.

Take a step back and ask yourself if this is really worth all the tension,
anger, and indignation. Obviously the answer is no.

Let's all- Developers, 'Designers', Admins, Remedy Folks, whatever- demonstrate
that we are 'professionals' with a sense of community first and foremost, and
put an end to this.

Cheers,

David C. Kirkpatrick
Sr. Systems Administrator, Remedy Developer, Designer, Remedy Guy, Jr. DBA,
Server Admin-type fella with a little bit of C++ experience on the side and a
darn good cook too!
The Regence Group
Portland, OR USA
503.225.6675 (phone)
dckirkp@regence.com


|--------+------------------------>
| | Art Milbuta |
| | | | PHONE.COM> |
| | |
| | 03/28/2001 |
| | 12:30 PM |
| | Please respond|
| | to "Action |
| | Request System|
| | discussion |
| | list(ARSList)"|
| | |
|--------+------------------------>
>----------------------------------------------------------------------------|
| |
| To: ARSLIST@LISTSERV.VISTAIT.COM |
| cc: (bcc: David C Kirkpatrick/BCBSO/TBG) |
| Subject: Re: Remedy vs. Visual Basic |
>----------------------------------------------------------------------------|






**

Try me again and see if my e-mail 'bounces'

PS If you can't take the heat, don't start a fire.

Art Milbuta
amilbuta@net2phone.com
973-412-3622

-----Original Message-----
From: Shannon Davis [mailto:sdavis@BCGI.NET]
Sent: Wednesday, March 28, 2001 10:17 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: Remedy vs. Visual Basic


**

I don't want to start an onlist flamewar, because this is certainly not
Remedy-related. I was going to take this offline - but wtf - I am also
offended. I just posted my opinions on a product - you have just insulted
my job performance. Besides, Art's mail just bounced - think he was
worried that
I might stand up for myself and removed his account before he could receive
my response?

Art seems to have missed the majority of my post where I defended Remedy as
a tool that serves its purpose very well, that I'm grateful to its
existence, and where I pointed out the existence of Modify All.

Boston Communications Group is very happy to have me, since I was the only
candidate in their three month search to have any Remedy Admin experience at
all, let alone the year of admin/development/troubleshooting that I do have.
I know that I'm not the consummate expert on the product - that's why I
joined this list - to learn more so that I can make our Remedy product work
even better.

I feel very sad to find that some members of this list can't have a
discussion on the pros and cons of Remedy without throwing punches at other
members.

-Shannon-
---
Shannon B. Davis
Remedy Systems Administrator
Boston Communications Group, Inc.
ph:(781) 904-5328
sdavis@bcgi.net

> -----Original Message-----
> From: Art Milbuta [mailto:amilbuta@NET2PHONE.COM]
> Sent: Wednesday, March 28, 2001 9:00 AM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> BRAVO ANN! I wonder if Boston Communications is aware that
> Shannon doesn't
> know very much about remedy?
>
> Art
>

________________
_____________


You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________



You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

_____________________________

**

Certainly, and I agree with the numbers idea. I just wanted to add what I
believe what those numbers will probably really show.

And now, as Patrick Zandi as asked, I will cease and desist from this
interesting but probably not so appropriate discussion on the ARS List.

Terrence J Hensley
Uni-Data Remedy Consultant

Check the possibilities:
http://www.sixfigureincome.com/?1239599

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> Sent: Wednesday, March 28, 2001 12:55
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> Terrence,
> "Remedy came to be with a niche in mind"
> I just wanna refresh the topic agian, the discussion is not Remedy's niche
> market, we're talking about Remedy vs. VB and the question is:
> does Remedy has
> full strength to be a player in the traditional c.s. programming
> tools arena?
>
> I totally agree with your statement about Remedy's dominence in
> it's Niche.
> I hope you can see the meaning of my numbers now!
>
> Regards...
> Ravi
>
>
>
>
>
>
>
>
> Terrence J Hensley @LISTSERV.VISTAIT.COM>
> on 03/28/2001
> 01:37:13 PM
>
> Please respond to "Action Request System discussion list(ARSList)"
>
>
> Sent by: "Action Request System discussion list(ARSList)"
>
>
>
> To: ARSLIST@LISTSERV.VISTAIT.COM
> cc:
> Subject: Re: Remedy vs. Visual Basic
>
>
> **
>
> I don't have any numbers to add, but I think you have struck upon a point
> without sayig. Remedy came to be with a niche in mind, and that was the
> services industry. As a result Remedy has proven to be very strong in that
> niche. Historically, if I am not mistaken, those who leave their niche
> usually find it a long road to haul to broaden their horizons. That is not
> to say that Remedy can't or shouldn't.
>
> A case in point from the archives,
>
> A Commodore computer was a game machine only - not for me - I used it like
> my current respectable system and seldomly used it for games. In
> fact I used
> it in a small business for a few years.
>
> Terrence J Hensley
> Uni-Data Remedy Consultant
>
> Check the possibilities:
> http://www.sixfigureincome.com/?1239599
>
> > -----Original Message-----
> > From: Action Request System discussion list(ARSList)
> > [mailto:ARSLIST@LISTSERV.VISTAIT.COM]On Behalf Of Ravi Bommareddy
> > Sent: Wednesday, March 28, 2001 10:40
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > Subject: Re: Remedy vs. Visual Basic
> >
> >
> > **
> >
> > One of my Analytical Chemistry lesson tells me that the some
> > facts are derived
> > from" Sampling"
> > So Let's give scintific sampling twist to this topic.
> >
> > 1. I believe 90% computing people doesn't know Remedy existence
>
> > call your
> > non-remedy developers and ask them what remedy do)
> > 2. About 99 % computing is done with non-remedy tools ( see the
> > combined revenue
> > figures for all software tools companies, like Microsoft's
> > SYBASE, SAP, SUN,
> > etc)
> > 3. Remedy's usage other than service industry( HD, AM, CM, CRM)
> > is almost none.
> > 4. Market cap for all software tools companies cross trillion
> dollars, but
> > remedy's is ~ 300 mill
> >
> > Help me out to give more #s, so we can get a conclusion
> >
> > Ravi :)
> >
> >
> >
> >
> >
> >
> > Rocky Rockwell @LISTSERV.VISTAIT.COM> on
> > 03/28/2001 11:14:53 AM
> >
> > Please respond to "Action Request System discussion list(ARSList)"
> >
> >
> > Sent by: "Action Request System discussion list(ARSList)"
> >
> >
> >
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > cc:
> > Subject: Re: Remedy vs. Visual Basic
> >
> >
> > I agree with most of what you say, however I prefer the word
> designer. The
> > reason I say designer is that we are limited to stay within 4
> > items (Active
> > Links, Filters, Escalation's and Menus). Yes we can do more
> > outside Remedy, but
> > we still have to stay within the 4 items by designing how the 4
> > items/modules
> > work.
> >
> > I have noticed that most developers (those with other language
> > skills i.e.: C,
> > C++ and even perl) have a very hard time understanding Remedy and
> > working within
> > the 4 items/modules. Yet and good Remedy designer (like some of
> > the people on
> > this this list) can write an application that rivals any C program.
> >
> >
> > rocky
> >
> > Ann Zbylut wrote:
> >
> > **
> >
> > I'm sorry, but I must take offense at your comment that you wouldn't
> > consider yourself a developer based on your Remedy development
> experience.
> >
> > In my mind, a developer is someone who can create a product that matches
> > the needs of the end user of that product, no matter what
> 'language' it's
> > written in. And I know plenty of 'developers' that can't seem
> accomplish
> > that (no matter what language).
> >
> > Remedy developers, in my experience, seem carry more of a load than the
> > typical programmer. There tends to be more customer contact
> and more of a
> > need for written, verbal, and people skills. Those, for many
> people, are
> > more difficult to master than programming skills.
> >
> > And yes, I have experience in other languages, including VB. My choice?
> > Remedy. Where else can you develop an enterprise-wide product
> in the same
> > century as when the!
> > requirements are delivered. Those of us without
> > patience will choose Remedy...
> >
> > I apologize for the rant, but I rarely feel this passionate about
> > a subject
> > and had to get this one off my chest...
> >
> >
> > Humbly,
> >
> > Ann Zbylut
> >
> >
> > On Mon, 26 Mar 2001 14:12:38 -0500, Shannon Davis
> wrote:
> >
> >
> >
> > **
> >
> > Ravi wrote:
> >
> >
> >
> > Yes, in End user terms we can this, "Remedy is also a
> > development tool"
> >
> >
> > I agree with you here. And many people would have difficulty
> > developing in
> > Remedy, even though it seems really easy to us.
> >
> >
> >
> > But if you look in depth about all this programming and
> > Database concepts, then
> > you will see the difference.
> >
> >
> > I definitely agree with you here. I have been working with C for
> > years and
> > am now learning C++, and I don't think Remedy is a comparable
> development
> > environment at all. It's not nearly as open-ended. But it
> does serve its
> > purpose and I wouldn't have a job without it.
> >
> > I'm doing Remedy now in the interim until I am qualified for a real
> > development position. I certainly wouldn't call myself a
> developer based
> >
> >
> > !
> >
> > on
> >
> >
> > my Remedy development.
> >
> >
> >
> > strict standards and rules. Where as in Remedy, you develop
> > your db along with
> > your app. To use a table in remedy you have to create it
> > through remedy. And you
> > don't know what's going on in db when you create a table.
> >
> >
> > It's really hard to explain to anyone with regular database
> > experience that
> > in Remedy, the table and the form are the same thing...that if
> I delete a
> > field from the form, it deletes all that data from the table.
> >
> >
> >
> > Remedy can update one record at a time. It's hard to
> > retrieve, update or insert
> > 20 child records on a single button click or event. Go and
> >
> >
> > What about 'Modify All' in the User Tool?
> >
> > ---
> > Shannon B. Davis
> > Remedy Systems Administrator
> > Boston Communications Group, Inc.
> > ph:(781) 904-!
> > 5328
> > sdavis@bcgi.net
> >
> > ______
> > _________
> >
> >
> > ______________
> >
> >
> >
> >
> >
> >
> >
> >
> > You may also control your subscription options, including
> UNSUBSCRIBE, at
> >
> >
> > www.ARSLIST.org
> >
> > ______
> > _______________________
> >
> >
> > You may also control your subscription options, including
> UNSUBSCRIBE, at
> > www.ARSLIST.org
> >
> >
> >
> >
> >
> > --
> > Thanks,
> >
> > Thanks,
> >
> >
> > Rocky
> >
> >
> > Rocky Rockwell
> >
> > Texas Instruments
> >
> > Plano, Texas
> >
> > Email: rockwell@ti.com
> >
> >
> > Phone: 972-927-9237
> >
> > ______
> > _______________________
> >
> >
> > You may also control your subscription options, including
> > UNSUBSCRIBE, at www.ARSLIST.org
> >
>
> ______
> _______________________
>
>
>
> You may also control your subscription options, including UNSUBSCRIBE, at
> www.ARSLIST.org
>
> ______
> _______________________
>
>
> You may also control your subscription options, including
> UNSUBSCRIBE, at www.ARSLIST.org
>

_____________________________



_____________________________