Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Converting Access to VB
- Thread starter moolie
- Start date
judgehopkins
Technical User
Can't do it.
I have seen programs out there that allege that they (the programs) can do that, but I have no experience with them.
"Be the first to say what is self-evident, and you are immortal." - M. Ebner-Eschenbach
I have seen programs out there that allege that they (the programs) can do that, but I have no experience with them.
"Be the first to say what is self-evident, and you are immortal." - M. Ebner-Eschenbach
- Thread starter
- #3
I have found a product on the web by Diamond Edge claiming to convert Access 2000 to VB6. In claims to convert forms, code modules etc to VB, reports to Crystal etc. Has anyone used this product? Does it do what it claims?
It's about 400 bucks(US) and I may just pick it up and give it a go.
It's about 400 bucks(US) and I may just pick it up and give it a go.
judgehopkins
Technical User
I would be interested in the results! Let me know.
judgehopkinsREMOVE@lycos.com
Thanks!
"The nice thing about being a celebrity is that when you bore people, they think it's their fault." - Henry Kissinger
judgehopkinsREMOVE@lycos.com
Thanks!
"The nice thing about being a celebrity is that when you bore people, they think it's their fault." - Henry Kissinger
- Thread starter
- #5
I got this e-mail in responce to one I sent requesting information from Diamond Edge.
>
> How does the converter handle Access subforms? Does it convert subforms to
>ActiveX user controls in VB or some other control?
It converts subforms into User Controls which is very similar to an Access subform.
>What percent of code conversion is usable in VB?
We typically see about 90% of the work automated. Which means it will save you a lot of time and easy pay for it self in what you save but will require you to do some of the work by hand.
>ODBC database
>connectivity vs. Jet or ADO connectivity etc.??
We typically recommend moving to ADO at the same time which means you may have some additional work if you choose this path. Though it not really that much work since the API to DAO and ADO Recordset is nearly identical and that is the object that is used most often in code. There is an option in our product to select which set of user interface controls to use ADO or DAO.
Regards,
Reed Ellsworth
--------------------------------------------------------------
Diamond Edge, Inc. Rock Solid and Cutting Edge Solutions
184 South 300 West
Lindon, UT 84042 801-785-8473 Voice & FAX
--------------------------------------------------------------
>
> How does the converter handle Access subforms? Does it convert subforms to
>ActiveX user controls in VB or some other control?
It converts subforms into User Controls which is very similar to an Access subform.
>What percent of code conversion is usable in VB?
We typically see about 90% of the work automated. Which means it will save you a lot of time and easy pay for it self in what you save but will require you to do some of the work by hand.
>ODBC database
>connectivity vs. Jet or ADO connectivity etc.??
We typically recommend moving to ADO at the same time which means you may have some additional work if you choose this path. Though it not really that much work since the API to DAO and ADO Recordset is nearly identical and that is the object that is used most often in code. There is an option in our product to select which set of user interface controls to use ADO or DAO.
Regards,
Reed Ellsworth
--------------------------------------------------------------
Diamond Edge, Inc. Rock Solid and Cutting Edge Solutions
184 South 300 West
Lindon, UT 84042 801-785-8473 Voice & FAX
--------------------------------------------------------------
MichaelRed
Programmer
The info in the e-mail is probably 'correct' as far as it goes. What isn't said (and probably true) is that the 90-10 (some use 80-20) rule applies.
If you aren't familair with the rule, it is oft used in project management, and is the succicent method of stating theat the larger ammount of work progress will take the smaller value of [time | effort | money | resources] (you select all that apply) while the smaller of the (see previous list) will require the larger (select from list).
90% of the work requires 10% of the resource -the remaining 10% of the work takes the other 90% of the resources.
So, the value really depends on the size of the project and the cost of the project. Smaller projects are clearly not worth the trouble, while the larger ones will obviously benefit - bit generally not improve the overall schedual by a lot.
Then, you say that the app " ... is outgrowing Access ... ", which is -at least to me- a somewhat amazing statement. Ms. A. does have some limitations, but the MAJOR issues are with the size of the DATA part and the speed of performance particularly with large data sources and network operations. These problems will persist in a simple conversion to VB, and even to the 'industrial strength' database servers (e.g. MS SQL Server, Oracle, ...) unless the data access portions of the app are carefully re-written -which I did not note as a part of what was touted as a feature of the 'autoconversion' program.
I am not 'knocking' VB or the programmatic conversion from Ms. A. to VB (or vice versa). I have -and expect to continue to use both (as well as other ;applications building products), I am simply noting that there is little compelling reason to do a conversion -and particularly on the basis of 'size' and/or 'growth'. The conversion will -in general- just add to the problems and delay the completion of the 'fix' to whatever real underlying problem(s) you already have. Switching the DATA to SQL Server (or your choice of the 'idustrial strength' database server can help in several respects BUT only if you use the capabilities which distinguish the server capabilities from the Jet db engine capabilities (stored procedures and 'pass through queries) are -perhaps= the two most prominient).
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
If you aren't familair with the rule, it is oft used in project management, and is the succicent method of stating theat the larger ammount of work progress will take the smaller value of [time | effort | money | resources] (you select all that apply) while the smaller of the (see previous list) will require the larger (select from list).
90% of the work requires 10% of the resource -the remaining 10% of the work takes the other 90% of the resources.
So, the value really depends on the size of the project and the cost of the project. Smaller projects are clearly not worth the trouble, while the larger ones will obviously benefit - bit generally not improve the overall schedual by a lot.
Then, you say that the app " ... is outgrowing Access ... ", which is -at least to me- a somewhat amazing statement. Ms. A. does have some limitations, but the MAJOR issues are with the size of the DATA part and the speed of performance particularly with large data sources and network operations. These problems will persist in a simple conversion to VB, and even to the 'industrial strength' database servers (e.g. MS SQL Server, Oracle, ...) unless the data access portions of the app are carefully re-written -which I did not note as a part of what was touted as a feature of the 'autoconversion' program.
I am not 'knocking' VB or the programmatic conversion from Ms. A. to VB (or vice versa). I have -and expect to continue to use both (as well as other ;applications building products), I am simply noting that there is little compelling reason to do a conversion -and particularly on the basis of 'size' and/or 'growth'. The conversion will -in general- just add to the problems and delay the completion of the 'fix' to whatever real underlying problem(s) you already have. Switching the DATA to SQL Server (or your choice of the 'idustrial strength' database server can help in several respects BUT only if you use the capabilities which distinguish the server capabilities from the Jet db engine capabilities (stored procedures and 'pass through queries) are -perhaps= the two most prominient).
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
The things I know are easy to do. The things I don't know are sometimes real hard.
There are lots of free programs to convert Access forms. They do not however convert the data handlers behind the forms. The limit to an Access database is two Gigs. I would suggest using Access or SQL Server to convert the data or the entire application. Neither will affect your present data, it will still be usable. If you can write the data handlers with VB then you will have no problem converting the application. If it is a huge application you might save some time with one on the conversion programs. Generally if you know how to convert it with the program, you can convert it without the program. If you can write ADO Data handlers it will be easy. VB does not help, you have to handle all your own errors and exceptions.
There are lots of free programs to convert Access forms. They do not however convert the data handlers behind the forms. The limit to an Access database is two Gigs. I would suggest using Access or SQL Server to convert the data or the entire application. Neither will affect your present data, it will still be usable. If you can write the data handlers with VB then you will have no problem converting the application. If it is a huge application you might save some time with one on the conversion programs. Generally if you know how to convert it with the program, you can convert it without the program. If you can write ADO Data handlers it will be easy. VB does not help, you have to handle all your own errors and exceptions.
- Thread starter
- #8
By upsizing to SQL server we are solving alot of performance deficiencies. SQL server manages memory differently than Access as well as provides the Multi-user control and security we are looking for. As for the code, all of the data access code is being re-written to run better (more discipline in relation to opening and closing connections and using standard database access protocols to eliminate unneeded connections)
MichaelRed
Programmer
the largest single improvement in performance will probably be from using views and stored procedures ON SQL SQLSERVWE, some improvement comes from using pass through queries, but not as much as SQL Server will always 'compile' the query on each instantation, where as Views are precompiled and stored procedures would generally be/use compiled objects.
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question