Visual Basic&database, Distribution of VB-constructed programs

Distribution of VB-constructed programs

Author	Message
Ken Andrew #1 / 7	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
Sat, 21 Sep 2002 03:00:00 GMT

Bob Butle #2 / 7	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.
Sat, 21 Sep 2002 03:00:00 GMT

Nick Leitc #3 / 7	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
Sun, 22 Sep 2002 03:00:00 GMT

Tim Smit #4 / 7	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
Sun, 22 Sep 2002 03:00:00 GMT

Art #5 / 7	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
Sun, 22 Sep 2002 03:00:00 GMT

Bob Butle #6 / 7	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.
Mon, 23 Sep 2002 03:00:00 GMT

poupae.. #7 / 7	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.
Fri, 27 Sep 2002 03:00:00 GMT

Page 1 of 1

[ 7 post ]