General "What is the best" question
I just want some general discussion .
I have been working with a company that has a software package written on a Unix machine and we need to move to windows. The software as it is cannot run on windows. So, I would like to know some pros and cons of the different programming enviornments out there. I can program in VB and Access, some C, some pascal and fortran. This will be a very data intensive suite of applications that will be run on a WAN as they have 3 different locations (ill, ms, fl).
Some on my requirements:
1. very fast data access
2. prefer an exe, but could handle having to load a runtime on each machine
3. handle true windows look/feel
4. DLL and OCX support (for addtional features later)
5. would like a small footprint, but I know that has a lot to do with the developer.
6. etc,etc,etc
I know this is all very vague, but I have some reservations about VB (I have heard it is not that fast).
I am just looking for different people's observations.
Thanks in advance.
I have been working with a company that has a software package written on a Unix machine and we need to move to windows. The software as it is cannot run on windows. So, I would like to know some pros and cons of the different programming enviornments out there. I can program in VB and Access, some C, some pascal and fortran. This will be a very data intensive suite of applications that will be run on a WAN as they have 3 different locations (ill, ms, fl).
Some on my requirements:
1. very fast data access
2. prefer an exe, but could handle having to load a runtime on each machine
3. handle true windows look/feel
4. DLL and OCX support (for addtional features later)
5. would like a small footprint, but I know that has a lot to do with the developer.
6. etc,etc,etc
I know this is all very vague, but I have some reservations about VB (I have heard it is not that fast).
I am just looking for different people's observations.
Thanks in advance.
VB might be only a tiny little bit slower, but it's not that significant a difference. It's rather fast actually. Especially if you create activex dll's. Since the activex dll's all make use the iclassfactory and the iunknown interface there will be no loss of speed in the execution. And since COM "should" also work on Linux (although some different approach is used) it can be multi-platform. Of course the same goes for any other language capable of COM programming.
Your reuirements:
1. very fast data access
>> Use ADO (ActiveX Data Objects). No matter what language you use the data access will be the same since you are using a component.
2. prefer an exe, but could handle having to load a runtime on each machine
>> ActiveX EXE can do that for you, but it doesn't really matter. Even a normal EXE will work.
3. handle true windows look/feel
>> VB, MFC, Delphi etc etc. Any language with a windows framework will do for fast windows development. WIn32 can do it too but will require you some additional coding, or using the resource editor.
4. DLL and OCX support (for addtional features later)
>> Every IDE which can create windows applications has support for DLL's and OCX's...See 3
5. would like a small footprint, but I know that has a lot to do with the developer
>> Meaning? Anyway, since you already have a working application and you need to port it to another platform I suggest you to look first for what language has been used and whether there are any parts that can easily be re-used. Foe example, if you built the app in C++, then it's very well possibe that you can copy a lot of code straight from the original. If that however is not the case and every source has something that is platform-specific, you cannot go for that approach. After that I suggest whether you want fast development. If you do then Delphi or Visual Basic will be excellent choices.
Another way might be to use COM and MTS. It is possible to use MTS to process an application that is running On Linix of Irix and other platforms. I have no idea how to set that environment up, but MS claims that it can be done... that way you only need to create some kind of VB wrapper / Delphi wrapper / whatsoever that calls the Linux process and have the eventual output come in the windows application. Best thing is to use DCOM for that so that all clients can connect to one server that contains the business logic.
Regards,
CJ
Your reuirements:
1. very fast data access
>> Use ADO (ActiveX Data Objects). No matter what language you use the data access will be the same since you are using a component.
2. prefer an exe, but could handle having to load a runtime on each machine
>> ActiveX EXE can do that for you, but it doesn't really matter. Even a normal EXE will work.
3. handle true windows look/feel
>> VB, MFC, Delphi etc etc. Any language with a windows framework will do for fast windows development. WIn32 can do it too but will require you some additional coding, or using the resource editor.
4. DLL and OCX support (for addtional features later)
>> Every IDE which can create windows applications has support for DLL's and OCX's...See 3
5. would like a small footprint, but I know that has a lot to do with the developer
>> Meaning? Anyway, since you already have a working application and you need to port it to another platform I suggest you to look first for what language has been used and whether there are any parts that can easily be re-used. Foe example, if you built the app in C++, then it's very well possibe that you can copy a lot of code straight from the original. If that however is not the case and every source has something that is platform-specific, you cannot go for that approach. After that I suggest whether you want fast development. If you do then Delphi or Visual Basic will be excellent choices.
Another way might be to use COM and MTS. It is possible to use MTS to process an application that is running On Linix of Irix and other platforms. I have no idea how to set that environment up, but MS claims that it can be done... that way you only need to create some kind of VB wrapper / Delphi wrapper / whatsoever that calls the Linux process and have the eventual output come in the windows application. Best thing is to use DCOM for that so that all clients can connect to one server that contains the business logic.
Regards,
CJ
A good choice is to use Oracle Server and Forms6i/Reports6i RAD development environment. If your application is for the back-office (not for intensive use with random visitors) you can deploy the application on Intranet/Internet without changes in the software. Also you can relay on Oracle Cherocee technology which will easy way to translate Forms/Reports code into dynamic HTML for embeding into JSP on WEB.
But you have to pay the price for your late technological transition - this means if you have no Oracle and RAD tools knowledge you will suffer - they are complex and it will take time to learn them.
To program data-centric applications using C++, VB looks strange. The cost of such projects is very high, the productivity is very low.
I provide you with details of a discussion on the Oracle Forms forum to hear also different opinions.
Joseph Schwertner
Friends,
Let us speak about Forms on WEB. I just set in "production" the "Personnel system" of my company. It is available only on Intranet, you cant use it. but the conclusions are interesting.
The main conclusion is: it works. The overhead exists (too much loading time at the beginning of the sesion). Another disadvantages: record navigation in multirecord blocks is confusing - very often the form looses the control over the navigation with mouse clicks. So I put the standard button "Next record" on the toolbar and recommend to use it. Also there are difficulties with iconic buttons - the images are not available, but I know what to do.
But there are big advantages. First at all the users have the whole Windows functionality in a WEB apllication - mouse clicks, tabs, multiwindows, the advanced Oracle Forms access to the Oracle DB. This is not the limited WEB page application, slow, stupid (from DB view of point of course). Also I would like to say that I succeed to make the application very fast and easy. My colleagues who make WEB apps using HTML and Java need as rule 5-6 men team to do the same. Of course it was not easy to learn how to deal with Forms Server and with Reports Server. So Forms really is a RAD.
As Mr. Alexander said Forms of the WEB are used in the so called "Back Office" implementations - for supporting the infrastructure of big enterprises. They are not approprite for random user access - the overhead is to big.
The next advantage of Forms on the WEB is that you escape the Forms Client instalation on every user station. You avoid to declare a remote directory with .fmx, to share the username/password/host with user. The only thing you do is to publish the URL. This is a big advantage.
About the overhead. In "old" environment (DB listener, Forms Server in the Forms Toolkit) the application really runs slow 9at the beginning of the sesion). But I sow apps based on iOAS9i and the integrated there Forms Server. They were fantastic fast (the overhead was 5 secs in comparison with the 40 secs on my computer).
I think that Oracle is doing the best to improve the functionality of Forms server. So now there are some disadvanteges of this technology, but I optimistically hope that in the next version there will be enhancements.
Maur?cio Pacheco (mauricio.pacheco@br.flext
Joseph is right and I would like to add
two things :
- Although there is some overhead in starting
Forms Server (let's say 20-40 seconds) the
usage is much faster than any HTML
application. Try to create in ASP a dynamic
page to query a table in tabular form with
page navigation (one of many examples).
While Forms needs 2 network packets, HTML
needs 15 (obvious because the data we see
is only a small part of the page, the rest
are tags, formatting information, scripts,
etc). This comparison was made with the
same table, showing the same columns and
with the same records/page. WEB Forms seems
slow but in fact is faster than HTML
because the GUI frame runs on the client.
- In one occasion there was an international
competition to create a WEB application
for product catalog (reports, queries,
maintenances, drawings, etc). While with
Forms we took 1 week (1 developer) the
fastest competitor took 3+ months (3
developers)! And worst, the user
functionality regarding complex queries and
reporting was far better in Forms than
the competitor's tool (I am not going to
give names). Perhaps this was a matter of
training but Forms is really fast to
develop database applications. If
productivity, simplicity, database
performance, data integrity and user
functionality is not important don't use
Forms.
Once more, Forms was not projected for public
sites where multimedia content and
presentation is required. It was projected
for authenticated database applications,
to handle and present data and to reduce
development and maintenance time.
But you have to pay the price for your late technological transition - this means if you have no Oracle and RAD tools knowledge you will suffer - they are complex and it will take time to learn them.
To program data-centric applications using C++, VB looks strange. The cost of such projects is very high, the productivity is very low.
I provide you with details of a discussion on the Oracle Forms forum to hear also different opinions.
Joseph Schwertner
Friends,
Let us speak about Forms on WEB. I just set in "production" the "Personnel system" of my company. It is available only on Intranet, you cant use it. but the conclusions are interesting.
The main conclusion is: it works. The overhead exists (too much loading time at the beginning of the sesion). Another disadvantages: record navigation in multirecord blocks is confusing - very often the form looses the control over the navigation with mouse clicks. So I put the standard button "Next record" on the toolbar and recommend to use it. Also there are difficulties with iconic buttons - the images are not available, but I know what to do.
But there are big advantages. First at all the users have the whole Windows functionality in a WEB apllication - mouse clicks, tabs, multiwindows, the advanced Oracle Forms access to the Oracle DB. This is not the limited WEB page application, slow, stupid (from DB view of point of course). Also I would like to say that I succeed to make the application very fast and easy. My colleagues who make WEB apps using HTML and Java need as rule 5-6 men team to do the same. Of course it was not easy to learn how to deal with Forms Server and with Reports Server. So Forms really is a RAD.
As Mr. Alexander said Forms of the WEB are used in the so called "Back Office" implementations - for supporting the infrastructure of big enterprises. They are not approprite for random user access - the overhead is to big.
The next advantage of Forms on the WEB is that you escape the Forms Client instalation on every user station. You avoid to declare a remote directory with .fmx, to share the username/password/host with user. The only thing you do is to publish the URL. This is a big advantage.
About the overhead. In "old" environment (DB listener, Forms Server in the Forms Toolkit) the application really runs slow 9at the beginning of the sesion). But I sow apps based on iOAS9i and the integrated there Forms Server. They were fantastic fast (the overhead was 5 secs in comparison with the 40 secs on my computer).
I think that Oracle is doing the best to improve the functionality of Forms server. So now there are some disadvanteges of this technology, but I optimistically hope that in the next version there will be enhancements.
Maur?cio Pacheco (mauricio.pacheco@br.flext
Joseph is right and I would like to add
two things :
- Although there is some overhead in starting
Forms Server (let's say 20-40 seconds) the
usage is much faster than any HTML
application. Try to create in ASP a dynamic
page to query a table in tabular form with
page navigation (one of many examples).
While Forms needs 2 network packets, HTML
needs 15 (obvious because the data we see
is only a small part of the page, the rest
are tags, formatting information, scripts,
etc). This comparison was made with the
same table, showing the same columns and
with the same records/page. WEB Forms seems
slow but in fact is faster than HTML
because the GUI frame runs on the client.
- In one occasion there was an international
competition to create a WEB application
for product catalog (reports, queries,
maintenances, drawings, etc). While with
Forms we took 1 week (1 developer) the
fastest competitor took 3+ months (3
developers)! And worst, the user
functionality regarding complex queries and
reporting was far better in Forms than
the competitor's tool (I am not going to
give names). Perhaps this was a matter of
training but Forms is really fast to
develop database applications. If
productivity, simplicity, database
performance, data integrity and user
functionality is not important don't use
Forms.
Once more, Forms was not projected for public
sites where multimedia content and
presentation is required. It was projected
for authenticated database applications,
to handle and present data and to reduce
development and maintenance time.
>1. very fast data access
needs refinement. Define. Sizes and distances and #users have impact, while most access methods have some built in efficiences.
>2. prefer an exe, but could handle having to load a runtime on each machine
I prefer exe as well
>3. handle true windows look/feel
VB
(optimize)
>4. DLL and OCX support (for addtional features later)
Microsoft. Visual Studio..
>5. would like a small footprint, but I know that has a lot to do with the developer.
Assembler.
Many many alternatives have built in needless overhead.
>6. etc,etc,etc
>>on a WAN
SQL
(prepare for data not on same machines)
>> reservations about VB
Try it. Is easier to get results, and not so slow as it had been. Then, if more speed needed, revisit relevant pieces, perhaps the communications.
>> software package written on a Unix machine
then C may be better 1st alternative, since it's code may likely be easier to move to alternative platform. If VC, then it can later be easier to move to VB for data or visuals since they use similar methods
needs refinement. Define. Sizes and distances and #users have impact, while most access methods have some built in efficiences.
>2. prefer an exe, but could handle having to load a runtime on each machine
I prefer exe as well
>3. handle true windows look/feel
VB
(optimize)
>4. DLL and OCX support (for addtional features later)
Microsoft. Visual Studio..
>5. would like a small footprint, but I know that has a lot to do with the developer.
Assembler.
Many many alternatives have built in needless overhead.
>6. etc,etc,etc
>>on a WAN
SQL
(prepare for data not on same machines)
>> reservations about VB
Try it. Is easier to get results, and not so slow as it had been. Then, if more speed needed, revisit relevant pieces, perhaps the communications.
>> software package written on a Unix machine
then C may be better 1st alternative, since it's code may likely be easier to move to alternative platform. If VC, then it can later be easier to move to VB for data or visuals since they use similar methods
Visual Studio
I recommend Microsoft Visual C++.
It can handle all of your requirements, there's plenty of help for it and it's fairly easy to learn.
For what you can't learn, it's easy to come back to and enhance.
Under certain circumstances, you can even write tight ASM code into it.
It can handle all of your requirements, there's plenty of help for it and it's fairly easy to learn.
For what you can't learn, it's easy to come back to and enhance.
Under certain circumstances, you can even write tight ASM code into it.
dchorton:
Just a friendly reminder and request to stay active in your questions.
thanks!
amp
community support moderator
2/4
Just a friendly reminder and request to stay active in your questions.
thanks!
amp
community support moderator
2/4
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
- PAQ'd and pts removed
Please leave any comments here within the
next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER !
Nic;o)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In such a case I would recommend Delphi.
But can you elaborate as to what your setup will be. Eg NT server for the database or whatever?