Re: Client Server Suggestions.

In article <1o9rfaINNoco_at_ef2007.efhd.ford.com> wwm_at_ef5003.efhd.ford.com (Bill Meahan) writes:
>In article <1808_at_ncrclm.ClemsonSC.NCR.COM> kmcclare_at_ncrclm.ClemsonSC.NCR.COM (Ken McClaren) writes:
>>
>>Hello all you netters,
>> I have an unusual question. We are moving from a COBOL based multiuser
>>type system to ORACLE version 6. My delima is what is the best way to develope
>>applications to operate in this new environment?
>>We operate on an Intel based multiprocessor 486/50 machine that is connected
>>to the users via a Novell network running TCP/IP. The operating sytem on the
>>client side is Dos/Windows3.1 on 386 or better systems.
>>
>>The new system must be.
>>1. Windows based.
>>2. Economical. We've looked at Gupta, but the per user connect fee is 300.00
>> too expensive for the risk, we have over 700 users.
>>3. It must be able to connect to Oracle now. Access does not have that
>> support yet.
>>4. It must be fast. We've also looked at Object View, but an interperative
>> system runs too slow for my 386/16mhz users.
>>
>
>Why not try Pioneer Software's Q+E Database Library with your choice of:
> Visual Basic
> Visual C++
> Excel
> <insert others here>
>
>The developer's kit is $399 and a corporate-wide distribution license is
>$999 (I don't know what the fee is for applications that are resold).
>
>You need ORACLE's SQL*Net too _at_$99/PC.
>
>Visual Basic will do everything that Gupta will do and requires no
>runtime license. Q+E Database Library does not require the creation of
>special tables in the database like Gupta does. Should you want to
>change tools or use multiple tools, the library supports a wide range of
>them (anything that can call a function in a DLL will do).

On the contrary... Although I have nothing against Visual Basic and have no experience with Q+E Database Library, I think that Gupta SqlWinddows 4.0 and ReportWindows 2.0 and Quest 2.1 offer a far more cohesive environment in which to develop client/server applications.

There is no doubt that Visual Basic offers a host of add-ins and the advantage of the no user license fee, this should not be the only decision about what environment can be chosen in developing an app. If cost is the major decision in picking tools to building apps that could come back to haunt you.

The problem with using an environment as described by the ealier post is that it could cause the following problems:

  Difficulty in maintaning the Application   Difficulty in isolating problems in a non-cohesive software solution   Increased learning curve to get started

Don't get me wrong, I don't think creating client/server apps in any env is a cake walk. But, I think life might be a little easier on you if you had a single vendor for your front-end application.

-- 
     ________________________________________________________________________
   //                                                                       //
  //  markp_at_netcom.com             Mark Perreira           (510)889-3373   //
 //_______________________________________________________________________//