Distribution of VB-constructed programs 
Author Message
 Distribution of VB-constructed programs

The firm where I work is looking at VB as a possible development
environment.  We're looking at VB Pro (VBP) and VB Enterprise (VBE).
However, I have a few questions for which I haven't found answers on the MS
website.

1) Do our clients need to purchase their own copy / copies of VB?  (I assume
the answer is NO.)

2) Assuming NO above, what portion(s) of VB must be given / exported to the
clients so that the code will run?  I'm thinking of things like DLLs.  Are
there costs associated with the distribution of such, i.e., are we required
to charge our clients and then pass royalties (or similar) back to
Microsoft?

3) When distributing our software to clients, is there anything inherent in
VB that limits them to how many active copies they can run simultaneously?
Are we forced to sell them multiple copies of something we construct, or can
we sell them one copy and they can run as many simultaneous instances of it
as they require?  If we are forced to sell multiple copies, how many
instances of each copy can they have running simultaneously?  1, 5, 10,
25...?  (We'd prefer just to sell them one copy, and have them run as many
instances as they need.)

4) What is the major difference between using VBP and VBE to design client
software?  Judging from what I've been reading, VBP is for single-user
stand-alone programs, while VBE is for multi-user programs.  Much of the
software we build is a multi-database package with multiple users accessing
one or more databases simultaneously.

5) We are currently using DB/C to construct our databases.  Is it possible
to use VB to construct a graphical front end to talk with the DB/C
databases?  As far as I know, DB/C is ODBC-compliant.

Many thanks for any information you can provide.

Ken Andrews



Wed, 18 Jun 1902 08:00:00 GMT  
 Distribution of VB-constructed programs

Quote:

> The firm where I work is looking at VB as a possible development
> environment. We're looking at VB Pro (VBP) and VB Enterprise (VBE).
> However, I have a few questions for which I haven't found answers on
the MS
> website.

> 1) Do our clients need to purchase their own copy / copies of VB? (I
assume
> the answer is NO.)

You assume correctly. Your clients do not need VB licenses, or VB
installed, to run your applications.

Quote:
> 2) Assuming NO above, what portion(s) of VB must be given / exported
to the
> clients so that the code will run? I'm thinking of things like DLLs.
Are
> there costs associated with the distribution of such, i.e., are we
required
> to charge our clients and then pass royalties (or similar) back to
> Microsoft?

VB comes with the Package & Deployment Wizard and you can also download
the new Visual Studio Installer from Microsoft.  Both scan your
applications and create setup packages with all necessary DLLs/etc.
The P&D wizard is pretty minimal functionality and has a number of
bugs, most of which have fairly easy workarounds.  The VSI looks better
but I have limited exposure to it to date.  Many developers purchase a
third-party package (e.g. InstallShield).

AFAIK, there are no royalties for anything that comes with VB with one
exception -- the picture/image controls support GIF format but the
license to use that is not granted through to the developer.  There is
some debate over whether that affects apps that use the controls but do
not deal with GIF files.  Most developers tend to ignore the issue
unless GIF processing is key to the application in which case they get
the proper licensing for it.

Other third-party controls may or may not require royalties or other
licensing.  You'd have to check that for any you consider buying.

Quote:
> 3) When distributing our software to clients, is there anything
inherent in
> VB that limits them to how many active copies they can run

simultaneously?
<cut>

What you do to limit the number of active instances is your call.  VB
imposes no restrictions in this area.

Quote:
> 4) What is the major difference between using VBP and VBE to design
client
> software? Judging from what I've been reading, VBP is for single-user
> stand-alone programs, while VBE is for multi-user programs. Much of
the
> software we build is a multi-database package with multiple users
accessing
> one or more databases simultaneously.

VB Enterprise includes little additional over VB Professional as far as
features needed to design and implement multi-tier applications.  The
main advantage to VB EE is the inclusion of Visual Source Safe which is
a source contrl package integrated with VB.  That, and some other
tools, can be very important in a team development environment.

VB Pro is fine for single-developer situations while VB Ent is better
for team situations.  Single-user/Multi-user apps can be developed in
either version.  Unless you are a very small shop (1-3 developers) I
wouldn't even consider the Pro version.

Quote:
> 5) We are currently using DB/C to construct our databases. Is it
possible
> to use VB to construct a graphical front end to talk with the DB/C
> databases? As far as I know, DB/C is ODBC-compliant.

I'm not familiar with DB/C so I can not answer other than to say that
if you have an ODBC-compliant driver then you SHOULD be able to connect
from VB.  Since this seems key to your operation I'd try to arrange a
test before buying to be certain.

--
Please reply via the newsgroup only

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 Distribution of VB-constructed programs

Quote:
> > 1) Do our clients need to purchase their own copy / copies of VB? (I
> assume
> > the answer is NO.)

> You assume correctly. Your clients do not need VB licenses, or VB
> installed, to run your applications.

your clients will just need the VB runtime files.

Mr. X



Wed, 18 Jun 1902 08:00:00 GMT  
 Distribution of VB-constructed programs

Quote:

> The firm where I work is looking at VB as a possible development
> environment.  We're looking at VB Pro (VBP) and VB Enterprise (VBE).
> However, I have a few questions for which I haven't found answers on the MS
> website.

> 1) Do our clients need to purchase their own copy / copies of VB?  (I assume
> the answer is NO.)

No.

Quote:

> 2) Assuming NO above, what portion(s) of VB must be given / exported to the
> clients so that the code will run?  I'm thinking of things like DLLs.  Are
> there costs associated with the distribution of such, i.e., are we required
> to charge our clients and then pass royalties (or similar) back to
> Microsoft?

Several DLL's are required to run VB applications, but these can be distributed
as you wish, with no royalties/licensing required

Quote:

> 3) When distributing our software to clients, is there anything inherent in
> VB that limits them to how many active copies they can run simultaneously?
> Are we forced to sell them multiple copies of something we construct, or can
> we sell them one copy and they can run as many simultaneous instances of it
> as they require?  If we are forced to sell multiple copies, how many
> instances of each copy can they have running simultaneously?  1, 5, 10,
> 25...?  (We'd prefer just to sell them one copy, and have them run as many
> instances as they need.)

You can run as many copies of a VB application as the system can handle without
running out of RAM etc. You may also need to check up on database multiaccess if
you want to run multiple apps all accessing the same database.

Quote:

> 4) What is the major difference between using VBP and VBE to design client
> software?  Judging from what I've been reading, VBP is for single-user
> stand-alone programs, while VBE is for multi-user programs.  Much of the
> software we build is a multi-database package with multiple users accessing
> one or more databases simultaneously.

Sorry, don't know on that one. AFAIK, Enterprise has got a few more features
(controls, wizards, etc)

Quote:

> 5) We are currently using DB/C to construct our databases.  Is it possible
> to use VB to construct a graphical front end to talk with the DB/C
> databases?  As far as I know, DB/C is ODBC-compliant.

VB can usually talk to any database system that uses ODBC. VB is ideally suited
to providing a GUI front end to databases.

Hope I could help,

--
-----------------------------------------------------------
* You're just jealous because the voices only talk to me.

Nick Leitch



Wed, 18 Jun 1902 08:00:00 GMT  
 Distribution of VB-constructed programs
But if you have a front end that is using Jet as the database - doesn't the
end user have to JET intsall.


Quote:

> > The firm where I work is looking at VB as a possible development
> > environment.  We're looking at VB Pro (VBP) and VB Enterprise (VBE).
> > However, I have a few questions for which I haven't found answers on the
MS
> > website.

> > 1) Do our clients need to purchase their own copy / copies of VB?  (I
assume
> > the answer is NO.)

> No.

> > 2) Assuming NO above, what portion(s) of VB must be given / exported to
the
> > clients so that the code will run?  I'm thinking of things like DLLs.
Are
> > there costs associated with the distribution of such, i.e., are we
required
> > to charge our clients and then pass royalties (or similar) back to
> > Microsoft?

> Several DLL's are required to run VB applications, but these can be
distributed
> as you wish, with no royalties/licensing required

> > 3) When distributing our software to clients, is there anything inherent
in
> > VB that limits them to how many active copies they can run
simultaneously?
> > Are we forced to sell them multiple copies of something we construct, or
can
> > we sell them one copy and they can run as many simultaneous instances of
it
> > as they require?  If we are forced to sell multiple copies, how many
> > instances of each copy can they have running simultaneously?  1, 5, 10,
> > 25...?  (We'd prefer just to sell them one copy, and have them run as
many
> > instances as they need.)

> You can run as many copies of a VB application as the system can handle
without
> running out of RAM etc. You may also need to check up on database
multiaccess if
> you want to run multiple apps all accessing the same database.

> > 4) What is the major difference between using VBP and VBE to design
client
> > software?  Judging from what I've been reading, VBP is for single-user
> > stand-alone programs, while VBE is for multi-user programs.  Much of the
> > software we build is a multi-database package with multiple users
accessing
> > one or more databases simultaneously.

> Sorry, don't know on that one. AFAIK, Enterprise has got a few more
features
> (controls, wizards, etc)

> > 5) We are currently using DB/C to construct our databases.  Is it
possible
> > to use VB to construct a graphical front end to talk with the DB/C
> > databases?  As far as I know, DB/C is ODBC-compliant.

> VB can usually talk to any database system that uses ODBC. VB is ideally
suited
> to providing a GUI front end to databases.

> Hope I could help,

> --
> -----------------------------------------------------------
> * You're just jealous because the voices only talk to me.

> Nick Leitch



Wed, 18 Jun 1902 08:00:00 GMT  
 Distribution of VB-constructed programs
Quote:
> 1) Do our clients need to purchase their own copy / copies of VB?  (I

assume the answer is NO)
        Right, the answer is NO

Quote:
> 2) Assuming NO above, what portion(s) of VB must be given / exported to

the clients so that the code will run?  I'm thinking of things like DLLs.
Are
Quote:
> there costs associated with the distribution of such, i.e., are we

required to charge our clients and then pass royalties (or similar) back to
Microsoft?
        VB comes with its own Setup/Deployment package. Once your project is
finished, just run the package to create a Setup program. This will include
all the necessary dependency files (.dll's, etc) that your project needs.
You can also manually add any other files that you want to include (i.e. If
you're using sound files in the project, etc). All the graphics files that
you placed in the form(s) would also automatically be included (that what
all the .frx files are)

Quote:
> 3) When distributing our software to clients, is there anything inherent

in VB that limits them to how many active copies they can run
simultaneously?
Quote:
> Are we forced to sell them multiple copies of something we construct, or

can we sell them one copy and they can run as many simultaneous instances of
it
Quote:
> as they require?  If we are forced to sell multiple copies, how many

instances of each copy can they have running simultaneously?  1, 5, 10,
Quote:
> 25...?  (We'd prefer just to sell them one copy, and have them run as many

instances as they need.)
        If you distribute by CD for example, there is nothing to stop them
from installing it on as many machines as they want. They can also run it as
often as they want (all at once) on one machine - limited only by computer
resources (Memory, etc). Of course, if you want to limit this, you would
have to code ways to prevent it.

Quote:
> 4) What is the major difference between using VBP and VBE to design client

software?  Judging from what I've been reading, VBP is for single-user
Quote:
> stand-alone programs, while VBE is for multi-user programs.  Much of the

software we build is a multi-database package with multiple users accessing
Quote:
> one or more databases simultaneously

        Not too sure here. I think the Enterprise edition includes
multi-Client/Server capabilities, but I've never run into any limitations.
There shouldn't be any database limitations in either version - that's
controlled by the database . . .

Quote:
> 5) We are currently using DB/C to construct our databases.  Is it possible

to use VB to construct a graphical front end to talk with the DB/C
Quote:
> databases?  As far as I know, DB/C is ODBC-compliant

        VB handles ODBC databases beautifully. If you're going with VB 6, I
strongly encourage you to make full use of the built in data environment -
this has simplified my development so much in terms of speed, simplicity and
lack of errors/bugs I can't rave enough about it . . .

HTH - E-mail me if you have more questions
artt at okanagan dot net



Wed, 18 Jun 1902 08:00:00 GMT  
 Distribution of VB-constructed programs


<cut>

Quote:
>         VB handles ODBC databases beautifully. If you're going with
VB 6, I
> strongly encourage you to make full use of the built in data
environment -
> this has simplified my development so much in terms of speed,
simplicity and
> lack of errors/bugs I can't rave enough about it . . .

What are you finding better than using straight ADO or DAO coding?
From everything I've looked at, and everything everybody I have talked
to about it, the data environment is just a thin wrapper around ADO and
essentially buys you nothing.  I use it only in design to determine
connection strings and sometimes toy with the data view to test
queries.  I would certainly never actually use it in an application
since it's just one more layer between my code and the database with no
apparent benefit.  I keep hoping somebody will demonstrate an advantage
to using it.

--
Please reply via the newsgroup only

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 Distribution of VB-constructed programs
We've had serious problems with the data environment on an SQLServer 7
database, because VB stores the compiled queries and fails to
synchronise (bug), so that once in a while your compiled queries are
out of synch with your text queries. Now you find the reason why your
code changes fail to show up at run time! My advice: stay away from the
data environment.

In the end, it's again one of those Mickey Mouse attempts to make
programming easier by using cartoons: it fails to address the real
problems in programming (and simplify those!), even though it's nice to
demo.



Quote:


> <cut>
> >         VB handles ODBC databases beautifully. If you're going with
> VB 6, I
> > strongly encourage you to make full use of the built in data
> environment -
> > this has simplified my development so much in terms of speed,
> simplicity and
> > lack of errors/bugs I can't rave enough about it . . .

> What are you finding better than using straight ADO or DAO coding?
> From everything I've looked at, and everything everybody I have talked
> to about it, the data environment is just a thin wrapper around ADO
and
> essentially buys you nothing.  I use it only in design to determine
> connection strings and sometimes toy with the data view to test
> queries.  I would certainly never actually use it in an application
> since it's just one more layer between my code and the database with
no
> apparent benefit.  I keep hoping somebody will demonstrate an
advantage
> to using it.

> --
> Please reply via the newsgroup only

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.


Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Distribution of VB-constructed programs

2. Having vb program create new distribution list in Outlook to send mail to

3. Accessing char ** C-programming Construct via DLL in VB5

4. VB programs distribution

5. Accessing char ** C-programming Construct via DLL in VB5

6. Accessing char ** C-programming Construct via DLL in VB5

7. Constructing a zip code program

8. How to construct a stacked chart in VB.net

9. VB & in memory tables and data constructs

10. Distribution of Access 97 program

11. Distribution of Program

12. Distribution for programs

 

 
Powered by phpBB® Forum Software