>>>>>Hi,
>>>>>At work we are upgrading all of our production systems to Oracle based products. There are some areas that are not covered by the new systems and need to be coded.
>>>>>
>>>>>We are all currently Fox2.6 and VFP3.0 programmers. Our mgmt is considering some of the top 4GLs as development environments. Powerbuilder, VB, Delphi, and Oracle's Developer 2000.
>>>>>
>>>>>The toss up is down to Powerbuilder and VB. I say if we're gonna pick VB, why not just stick to VFP5.0, but failing that argument. I have some ??s comparing VB to VFP:
>>>>>1) I know you can connect to a Fox DBF in VB, but can you "Seek" and open Fox CDXs?
>>>>>2) Is it easier to connect to an Oracle table with VFP5 or VB5. Oracle is sitting on DEC Unix.
>>>>>
>>>>>Thankx
>>>>>John Morga
>>>>
>>>>
>>>>The ease of connecting to Oracle will be about the same in VB as in VFP. Both will use the same ODBC drivers. However...you'll need to do something with that data once you've pulled it locally. This is where VFP really outshines VB. Also...VFP is OO...VB is not, it is object based. What this relates to is decreased development time. Also, you need to consider the retraining to learn VB..
>>>>
>>>>You might want to take a look at the whitpaper comparing VB, VFP, Access, & MS-SQL Server. It is available at www.microsoft.com/vfoxpro.
>>>>
>>>>Craig
>>>
>>>John,
>>>
>>>I'll throw my 2 cents worth into the fray and agree with Craig. I've never used VB, but know several who do and I seem to have a better time with VFP than they do with VB. They are all howling for the same OOP setup as VFP. I'd stick with it.
>>>
>>>Steve Despres
>>
>>
>>Yup. I tried playing with VB about a year ago and kept wanting, wanting, wanting OOP.
>>
>>Craig
>
>Hi
> What about Oracle Developer 2000?? Main advantage in this case
>will be you don't have to do ODBC at all!!! Being a front end of
>its own RDBMS backend it will be much more powerful & efficient
>than any other front end. ODBC is slower in performance than the
> native drivers. Also you can use Backend features which are not
> supported through standard ODBC/SQL calls.
>
>Narendra

For me, the cost of Oracle and the difficulties in maintaining it far outway the advantages of not using ODBC.

Craig