Vb/vba?

[hi there]

i know similar questions like this have been asked numerous times and i apoligize if this seems repetitive. i've read through the other posts but i'm still looking for an answer. he goes:

1. VB has come up at work lately and was wondering just how different VB is from VBA. folks at my work have been asking a lot of questions about developing larger client/server type applications. that has led me to do some research on SQL server applications. i've read people recommending using SQL server with a VB front end so naturally i'm wondering how involved is it in developing this VB front end as opposed to an Access front end?

2. can i use what little VBA knowledge i have to work with VB?

3. furthermore, do y'all see any advantage to using a VB front end as opposed to an Access front end?

4. and lastly has anyone had any experience with a book titled "VB and VBA in a Nutshell." i kinda looking for a book that compares the 2 languages and notes the differences.

as always i am extemely grateful to any and all responses to my questions. many thanks.

 

[llkhoutx]

VBA is a subset of VB and and to me is more user friendly that VB. I'm sure someone will post a more technical answer to your question.

As I recall, "VB and VBA in a Nutshell" just addresses the instruction set as opposed to how to use it. If that's what you're looking for OK.

 

[Pat Hartman]

VB is a full featured stand-alone programming language. Its development environment is not as user friendly as that of Access since more code is required to accomplish the same tasks. With Access you can build a large part of your application without writing a single line of VBA. That is not the case with VB.

You will find the event and properties model of VB forms/reports just enough different from Access to cause trouble.

VBA is an embedded language and is intended to be used within the context of some other application such as Access or Excel (it is also sold to OEM's so you will find non-Microsoft apps that also use VBA). Because of its purpose, there is a core language and then additional functionality that varies from implementation to implementation. For example, the Access form events and properties are different from Word or Excel. Access would have no use for the mail-merge language elements. Functions that have the same name (such as Sum()) are implemented differently between Access and Excel simply because a table is very different from a spreadsheet. In Excel the argument for Sum() (and other aggregate functions) is much more complex. It can be multi-part and it can specify virtical as well as horizontal ranges. In a table, it can only specify a column name (or an expression) and there is no end to the range. The range is controlled by the where clause and the Group By clause.

 

[hi there]

thanks for the responses pat and llkhoutx. they were very helpful. i understand that VBA comes in many different flavors (Access, Excel, PowerPoint, Outlook,...etc) and syntax will vary based on the applications object hiearchy and application functions. does anyone have any opinion about the question of using Access as the front end for a client/server application as opposed to VB. based on your reponse pat it seems like VB is a much more robust language capable of doing much more (e.g. interacting with other applications) than VBA. however it also seems like i'm going to have a learning curve. so do you think the benefits outweigh the costs?

thanks everyone

 

[Pat Hartman]

Access makes a fine front end in a client server environment. Each user can have his own copy of the fe db so there is no real limit to the number of users. The official max users for a db is 255. The practical limit is much lower according to the posters here so the separate copies gets by that problem. The be is a little more of a problem. Depending on the size of the database and the number of users, you may need to "upsize" to something like SQL server, DB2, or Oracle depending on your shop standard.

If I were going to make a retail application and I didn't want customers to have to deal with the Access runtime, I would strongly consider VB even though the development time is substantially longer. But I'm a "real" programmer. For an inhouse app where users have a retail version of Access available or have a standardized environment which will minimize problems with the Access runtime, I would use Access as the fe. There is much less manual work involved.

Access is a much more user friendly development environment than other options. It is intended to be usable by people with little or no training. That doesn't mean that untrained people should be entrusted to be making applications (as reading the posts here should make evident). Access is not automatically robust but neither is VB or any other language. It is up to YOU the developer to make sure the database is properly defined, the data is properly edited, the GUI makes sense to the user, and all errors are trapped. So in fact, despite outward appearances, Access is not as easy as Microsoft would have customers believe.

 

[hi there]

hi pat. thanks for all the information. as always your responses are very helpful. i've read several of your posts where you describe using Access as a front end to more powerful applications like Oracle. i think this is probably the way for me to go, but i'm still confused about how i would incorporate a client/server application using individual Access front ends. in these instances are you using the MSDE? will using Access as a FE prevent me from harnessing the power of the "true" client/server applications like SQL Server, Oracle,...? would this be an implementation/maintenance nightmare over a large corporate network? i've just completed a small application for a facility's local network where i split the dbase into FE/BE (both Access) and placed copies of FE on each users desktop, but it does get a little slow when 7 or so users are updating records. it can also be somewhat of a nightmare when i have to make changes to the dbase and re-destribute it. i've read some posts on the forum and writing batch files to help with this, but i need to do some more research before attempting this. thanks again for all your comments.

 

[Pat Hartman]

Almost all my assignments are with large corporations. So far I haven't had a db with hundreds of users but it is certainly possible.

In a large company, you will probably have the option of having your fe "pushed" by system software when a user logs on. If that facility is not available, I would use the two-table method that I wrote about some time ago. Put a table with a date/time field in the back end and link it to the fe. Put an identical table physically in the fe (different name of course). Run a query on start up that compares the timestamps in both tables. If they are identical, proceed. Otherwise tell the user he needs to download a new copy of the fe and close the db.

 

[hi there]

thanks pat. i've read one of your posts where you describe this method of placing a timestamp table in the FE and BE and notifying the user when an update is necessary. it looks like i've got a lot more studying to do before i attempt such an application, but thank you again for all of your responses. now i have a better idea of what direction i should pursue.

many thanks