VB4 vs. VB5 vs VB6 for database applications
| Author |
Message |
|
Erick Thomps
#1 / 4
|
 VB4 vs. VB5 vs VB6 for database applications Hello, I am currently starting a large contact and document
management system, with SQL server 6.5 as the back end, and VB as the
front end. I currently have a copy of VB4, but I don't know if this is
the best product for this project. Some of the concerns that I have
are:
Performance (some of the clients will be mid range 486s with 12 megs)
When VB4 makes an executable, does it actually compile the program?
I've heard that VB5 and above do this, but I don't have a strong
source on that. Is there a lot of feature creep in VB5 and VB6 that
would slow things down? Any comments?
DB functionality
I've read the material on the MS website, and one of things that they
talk about the DB centered ability of VB6. Has anyone worked with VB6
in this context? Is it a lot easier to develop DB frontend apps with
VB6?
Ability to integrate with Office applications
Does VB5 or VB6 have more functionality then VB4 is this area? I know
everything is possible with OLE, but I would perfer something a little
more. For example, Access 95 has the office links buttons, which do a
good job and are easy to set up.
If anyone has any other comments/suggestions, please let me know.
Thank you,
Erick Thompson
|
| Fri, 02 Mar 2001 03:00:00 GMT |
|
 |
|
Oscar Bowye
#2 / 4
|
VB4 vs. VB5 vs VB6 for database applications Erick, Your big issue may be Win 3.x client computers. VB4 is the last version that will run on Win 3.x (16 bit). 12 Meg of memory may mean you have to unload all unused forms and data and reload when needed. This will make responsiveness worse but will help prevent "out of memory" errors or slow response from other running apps. Hope this helps. Oscar Bowyer
Quote:
>Hello, > I am currently starting a large contact and document
>management system, with SQL server 6.5 as the back end, and VB as the
>front end. I currently have a copy of VB4, but I don't know if this is
>the best product for this project. Some of the concerns that I have
>are:
>Performance (some of the clients will be mid range 486s with 12 megs)
>When VB4 makes an executable, does it actually compile the program?
>I've heard that VB5 and above do this, but I don't have a strong
>source on that. Is there a lot of feature creep in VB5 and VB6 that
>would slow things down? Any comments?
>DB functionality
>I've read the material on the MS website, and one of things that they
>talk about the DB centered ability of VB6. Has anyone worked with VB6
>in this context? Is it a lot easier to develop DB frontend apps with
>VB6?
>Ability to integrate with Office applications
>Does VB5 or VB6 have more functionality then VB4 is this area? I know
>everything is possible with OLE, but I would perfer something a little
>more. For example, Access 95 has the office links buttons, which do a
>good job and are easy to set up.
>If anyone has any other comments/suggestions, please let me know.
>Thank you,
>Erick Thompson
|
| Fri, 02 Mar 2001 03:00:00 GMT |
|
|
|
Remove NOSPAM to rep
#3 / 4
|
VB4 vs. VB5 vs VB6 for database applications Erick, I agree with Oscar, the ONLY reason you would want to stick with VB4 is if
you have any 16-bit clients (Windows 3.X). Even so, I would push them to
move to a 32-bit system. VB6 is the way to go if you have 32 bit clients.
It does compile to native code although it does have a large code library in
the form of a big .dll file. It is significantly faster than VB4. VB6 uses
ADO as its data access method which will work very well with SQL Server. On
those machines with only 12 MB and 486 processors, why on earth would they
stick with that platform? For very little money $150 you can upgrade to a
Cyrix 686MX, M2, or AMD K6 processor with motherboard and get Pentium 166 or
200 level performance. RAM, in Northern California anyway, is running about
$35 for 32MB. For $200 or so, they could be running on a decent platform,
they would make the $200 back in productivity in a month or so. If they
have the money to pay you on a large contract, they should have the money to
upgrade to more current technology.
Quote:
>Hello, > I am currently starting a large contact and document
>management system, with SQL server 6.5 as the back end, and VB as the
>front end. I currently have a copy of VB4, but I don't know if this is
>the best product for this project. Some of the concerns that I have
>are:
>Performance (some of the clients will be mid range 486s with 12 megs)
>When VB4 makes an executable, does it actually compile the program?
>I've heard that VB5 and above do this, but I don't have a strong
>source on that. Is there a lot of feature creep in VB5 and VB6 that
>would slow things down? Any comments?
>DB functionality
>I've read the material on the MS website, and one of things that they
>talk about the DB centered ability of VB6. Has anyone worked with VB6
>in this context? Is it a lot easier to develop DB frontend apps with
>VB6?
>Ability to integrate with Office applications
>Does VB5 or VB6 have more functionality then VB4 is this area? I know
>everything is possible with OLE, but I would perfer something a little
>more. For example, Access 95 has the office links buttons, which do a
>good job and are easy to set up.
>If anyone has any other comments/suggestions, please let me know.
>Thank you,
>Erick Thompson
|
| Sat, 03 Mar 2001 03:00:00 GMT |
|
|
|
Erick Thomps
#4 / 4
|
VB4 vs. VB5 vs VB6 for database applications On Tue, 15 Sep 1998 07:17:08 -0700, "Jose Lopez (Remove NOSPAM to Quote:
>Erick, >I agree with Oscar, the ONLY reason you would want to stick with VB4 is if
>you have any 16-bit clients (Windows 3.X). Even so, I would push them to
>move to a 32-bit system. VB6 is the way to go if you have 32 bit clients.
>It does compile to native code although it does have a large code library in
>the form of a big .dll file. It is significantly faster than VB4. VB6 uses
>ADO as its data access method which will work very well with SQL Server. On
>those machines with only 12 MB and 486 processors, why on earth would they
>stick with that platform? For very little money $150 you can upgrade to a
>Cyrix 686MX, M2, or AMD K6 processor with motherboard and get Pentium 166 or
>200 level performance. RAM, in Northern California anyway, is running about
>$35 for 32MB. For $200 or so, they could be running on a decent platform,
>they would make the $200 back in productivity in a month or so. If they
>have the money to pay you on a large contract, they should have the money to
>upgrade to more current technology.
Well, the organization in question is a non-profit, and has the budget determined by the people who donate the money. So to upgrade the systems, we must wait for someone who wants to donate money to a capital project. Thanks for the info with VB6. I'm glad it will be faster, as I would rather use it. Quote:
>>Hello,
>> I am currently starting a large contact and document
>>management system, with SQL server 6.5 as the back end, and VB as the
>>front end. I currently have a copy of VB4, but I don't know if this is
>>the best product for this project. Some of the concerns that I have
>>are:
>>Performance (some of the clients will be mid range 486s with 12 megs)
>>When VB4 makes an executable, does it actually compile the program?
>>I've heard that VB5 and above do this, but I don't have a strong
>>source on that. Is there a lot of feature creep in VB5 and VB6 that
>>would slow things down? Any comments?
>>DB functionality
>>I've read the material on the MS website, and one of things that they
>>talk about the DB centered ability of VB6. Has anyone worked with VB6
>>in this context? Is it a lot easier to develop DB frontend apps with
>>VB6?
>>Ability to integrate with Office applications
>>Does VB5 or VB6 have more functionality then VB4 is this area? I know
>>everything is possible with OLE, but I would perfer something a little
>>more. For example, Access 95 has the office links buttons, which do a
>>good job and are easy to set up.
>>If anyone has any other comments/suggestions, please let me know.
>>Thank you,
>>Erick Thompson
|
| Sat, 10 Mar 2001 03:00:00 GMT |
|
| |
|
