Do VB 6 Skills transfer well to Access? 2

[lameid]

Obviously, VB6 is more versatile than Access but would someone that has experience with VB6 be able to pick up Access quickly?

If it is dependent on certain VB6 functions or concepts please give me specifics. Unfortunately, I do not have VB6 experience to be able to ask good interview questions.

I always figured that anything that was VBA had an almost one to one line up in VB6. And then the other objects could be generated in some shape or form (except tables instead use a RDBMS) but are harder to generate as a lot of the Access Object structure would have to be coded manually. Am I way off the mark?

I have been programming in Access for 8 to 9 years now. I probably know how to do almost everything Access can be kicked into doing. So please, be as thorough or specific as you are willing.

Thanks so much in advance...

I guess I'll be digging up the VB6 in record time book I sadly never got to look at.

 

[jsteph]

From a coding standpoint, anyone with vb6 skills would already know the language behind access. However, dealing with Access form objects, report objects, sql skills, and table design and database architecture are each skills in their own, and a VB6 expert might not know diddly about relational database design. Access form objects are close to VB6 forms, but not the same. Access reports are much different than the vb6 report designers, or Crystal, for that matter.

In my opinion, the VB6 language is the easier to learn. So if I were hiring for an Access position--specifically one that involved designing table structures, etc, I'd take someone with, say, a db-design background and no VB6 over someone with VB6 skills but no db design skills, it's easier to learn VBA than to learn efficient db design.
--Jim

 

[lameid]

Thanks for the feedback, the person I'm looking at happens to have SQL server background and Access Backend background so I would have no problems with table /database design other than of course that the business rules here bend on a whim and IT (me) has little input into business process (limits).

I have not seen the VB6 report designer... You said it is nothing like Access reports nor Crystal? Having seen Crystal and hardly used it, my opinion is that Crystal is somewhat similar to Access (although adding a band for each line drives me crazy). Could you rank Access and Crystal similiarities on a scale of 1 to 10 with 10 being the same and 1 comparing an Earthworm to Office 2003. Please do the same for Access and VB6 reports? That would give me some good idea as to how different they are.

Personally though, I find reports about the same as forms for design. You just add sorting and grouping and know you can use any of the SQL aggregate functions. It doesn't get ugly until you have to write on format event code. Do you agree that if you understand Access forms (similar to VB6), then the next step to Access reports is not a big one? I'm guessing the learning curve would not be all that steap.

If you can answer this for me, great... How big of a jump is it from VB6 to VB.net? How about from Access to VB.Net?
I am thinking the other way to go is to abandon Access for new development and move to VB.Net.

Your feedback thus far is really appreciated.

 

[jsteph]

lameid,
I've not yet made the jump to .Net myself, so I can't comment on the similarities, but from what I know about Object Oriented tools, .Net will be fundamentally different than VB 'classic'. I will wait until the "DLL Hell" that we're now experiencing with .Net (funny, I thought .net was supposed to eliminate that) is straightened out. By this I mean, which version of .Net does the client have--1.1, 2.0, and which version are we developing in, is it backwards compatible (no from what I hear), etc, etc??? Ok...end of that rant.


As far as reports, my overall preference is Access reports, but that's mainly due to the comfort level. I think the whole grouping thing is handled differently between Crystal and Access, so I'd say it's only a 5 in terms of similarity.

Crystal does not (as far as I know) have the code-behind-events that Access does. To me, this adds a tremendous amount of flexibility. Yet Crystal has the canned report ability, ie, sending data with the report via email, where with Access you need the snapshot viewer, the right version, etc, etc, on any client where you'd send a snapshot. Crystal also has the ability to connect to a very wide range of data sources, but so does Access, however Crystal has it's enterprise version and that is far more useful and more efficient than Access if you're reporting needs are truly enterprise in scale.

As far as basic report-building, I guess knowing Access forms is a good head-start. But with reports, the whole concept of grouping, totalling, etc is one that is really a seperate skill apart from dragging textboxes onto a screen.

So, just like db-designng is a more important skill than learning the syntax of a tool, with reports, the dealing with end users, making sure the specs for the report are fully understood by both the developer and the end user--what the data means and why it's grouped this way or that way, and how to build the correct sql source or procedure for the report, etc, are extremely important and harder to learn than the rote dragging of textboxes onto the screen.
--Jim

 

[Golom]

If I were to rank the three (Access Reports, VB6 Report Designer, Crystal) it would probably be something like
[tt]
System Ease of Use Power
Access 8 5
VB6 7 3
Crystal 4 10
[/tt]
Crystal (now Business Objects) is a full fledged development environment in its own right. It's much larger and more complex than the other two and has a much steeper learning curve.

Access is a product that MS will (presumably) support and enhance for the forseeable future. VB6 is a discontinued product. VB.Net is the current latest and greatest. While I'm an experienced VB6 developer I would certainly not recommend that anyone looking for a new development platform choose it. All the new stuff will be happening in VB.Net and your choice is probably between Access and VB.Net.

Of course, if you are contemplating moving to the "big boys" in the RDBMS world (i.e. SQL Server, Oracle) then the Access route gets a bit problematic. You can certainly front-end those systems with Access but its difficult to exploit their full power through Access.

 

[lameid]

Golom,

We have SQL Server and going forward have to use it to eliminate problems with performance (presumably caused by locking and transaction throughput in addition to JET's File scans).

I guess my question is, why is it difficult to exploit the power of RDBMS's through Access? My impression was that it would not be any more incrementally difficult to perform the same tasks in Access than one of the VB versions or one of the other Object Oriented Languages. Certainly there it is easier to get to more granular control than Access but don't the benefits of Access in ease of screen development, reporting etc. out weigh the difficulties? I guess ultimately it all boils down to the task at hand... So maybe an example of what would be hateful but easy or tolerable in the other platform may give some added insight.

Perhaps you may be able to provide some added insights into what you think is best by knowing a little more of my situation... The company is high revenue, low profit (less than 5%) and small as far as employee count goes. We run about 25 people.

 

[jsteph]

Lameid,
I'll add a bit here about exploiting the power of an rdbms using access as a front-end. When you're talking about reporting, you're typically going to define the report and know what the final field-set is, regardless of how many tables/queries, etc, go into creating the report. So for the more complex ones, I'll create the final table in sql-server, and have a stored procedure that runs all of the complex sql to arrive at the result set, which is loaded to that table. This table can be id'd by a workstation field, so that multiple workstations can run the same report without contention. The report can run with that table odbc-linked as a source, or via a pass-thru query accessing that table.

Then I have some simple reports that read from a single table, and it's a simple report based on a Pass-thru query, who's sql is built based on criteria parameters in a form. The performance is extremely fast, there's no noticeable penalty for using Access as opposed to Crystal, VB or whatever alternatave reporting tool one might use.

The idea is to use Access as as thinly as possible, ie, only using as little as possible in terms of objects--a pass-thru query as opposed to an odbc-linked table with a jet query as the report's recordsource.
--Jim

 

[lameid]

Right, the Client-Server rule of thumb: Do as much as possible server side to reduce the bottleneck of the network. This also lends itself to having beefy servers and thinner clients.

Jim I aprreciate your feedback. It just seems like Golom meant something more... From where I sit you'd have to do the same work to get a result out of an RDBMS whether you are talking VB, Crystal or Access. The only real differences I would expect are how you pass parameters to the RDBMS and how you get your application to handle the data. IN access I believe there are properties you can set to conrol values passed to a recordsource. Not to mention the SPT (SQL Pass Thru) queries.

Is using an RDMS more work than JET in Access? Definitely.

Is it any worse than using and RDBMS in VB? I doubt it, maybe equivalent to it. Am I wrong here?