By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,492 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

Access to ASP/VB.net converters

P: n/a
It looks like I may have to convert my Access mdb to be used on the web
(terminal services is not an option).

In doing a search, I've found several converters that look interesting,
specifically:

1) Microtools.us
2) EvolutionSoft

Does anyone have any experience with these or with other converters.

My app has about 150 forms, close to 100 tables and around 10000 to 15000
lines of VBA code.

Thanks.

--
Message posted via http://www.accessmonster.com
Jan 11 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
robert d via AccessMonster.com wrote:
It looks like I may have to convert my Access mdb to be used on the web
(terminal services is not an option).

In doing a search, I've found several converters that look interesting,
specifically:

1) Microtools.us
2) EvolutionSoft

Does anyone have any experience with these or with other converters.

My app has about 150 forms, close to 100 tables and around 10000 to 15000
lines of VBA code.

Thanks.

This link contains a summary of my results from researching the same
thing.

http://members.cox.net/tulsaalstons/...onSoftware.htm

Bottom line, there really isn't anything available that will do the
whole job for you. But if you are willing to debug code, one of the
products looked pretty good for a 90% or so solution: Microtools AccessWiz.

Bob
Jan 11 '06 #2

P: n/a
Thanks, Bob.

This is great information!

Bob Alston wrote:
It looks like I may have to convert my Access mdb to be used on the web
(terminal services is not an option).

[quoted text clipped - 11 lines]

Thanks.


This link contains a summary of my results from researching the same
thing.

http://members.cox.net/tulsaalstons/...onSoftware.htm

Bottom line, there really isn't anything available that will do the
whole job for you. But if you are willing to debug code, one of the
products looked pretty good for a 90% or so solution: Microtools AccessWiz.

Bob


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200601/1
Jan 11 '06 #3

P: n/a
robert d via AccessMonster.com wrote:
Thanks, Bob.

This is great information!

Bob Alston wrote:
It looks like I may have to convert my Access mdb to be used on the web
(terminal services is not an option).


[quoted text clipped - 11 lines]
Thanks.


This link contains a summary of my results from researching the same
thing.

http://members.cox.net/tulsaalstons/...onSoftware.htm

Bottom line, there really isn't anything available that will do the
whole job for you. But if you are willing to debug code, one of the
products looked pretty good for a 90% or so solution: Microtools AccessWiz.

Bob


You should probably look into Microsoft's new Visual Web Developer 2005
Express which is out in gold release and currently free. You can do a
lot of forms connected with databases without coding. Clearly there
would be a learning curve but it would be native .NET Some books have
recently become available on Amazon on this software. And one title is
available free in electronic form.

You might also talk to one of the guys on this newsgroup who has good
experience using Access data access pages. I encountered some security
issues in the interface it uses for connection to a database (e.g. not
in data access themselves)- in a 3-tier environment that I have read
cause most commercial hosting services not to permit them to operate.
However, in a 2-tier environment, I understand they work fine. If you
have the ability to control the host server, and put the Access/Jet
database (e.g. the MDB file, not really Access) maybe that avenue will
be fruitful.

"lylefair" may be able to add his experience .....

If you search on my last name "Alston" in this newsgroup you will be
able to read about my interaction with lylefair on this topic.

Good luck.

Bob

I think you will have great difficulty converting your existing Access app.
Jan 11 '06 #4

P: n/a
>I think you will have great difficulty converting your existing Access app.

Yes, I suspect that you are correct. Virtually all of my forms are unbound
and I use DAO exclusively.

I'm going to recommend to the client that they consider terminal services.
If they insist on ASP, so be it; they'll be the ones paying for it.

Thanks.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200601/1
Jan 11 '06 #5

P: n/a
"robert d via AccessMonster.com" <u6836@uwe> wrote in
news:5a35aef12fafa@uwe:
I'm going to recommend to the client that they consider terminal
services. If they insist on ASP, so be it; they'll be the ones
paying for it.


What do they think they will be getting with an ASP solution that
will be worth the hugely larger investment?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 11 '06 #6

P: n/a
Not sure yet. I haven't made the pitch yet, but I just have the feeling that
there consultant is pushing a totally web-based solution.

There network solutions are slow, so, correct me if I'm wrong, but wouldn't a
terminal services solution where the Access front end and the SQL Server
backend are located on the same server provide relatively fast response. Do
you think it would be faster than an ASP front end?

David W. Fenton wrote:
I'm going to recommend to the client that they consider terminal
services. If they insist on ASP, so be it; they'll be the ones
paying for it.


What do they think they will be getting with an ASP solution that
will be worth the hugely larger investment?


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200601/1
Jan 12 '06 #7

P: n/a
"robert d via AccessMonster.com" <u6836@uwe> wrote in
news:5a3a524d21816@uwe:
Not sure yet. I haven't made the pitch yet, but I just have the
feeling that there consultant is pushing a totally web-based
solution.
Sounds to me like a straight cost/benefit analysis ought to take
care of it. Setting up a Terminal Server is comparatively easy and
inexpensive (though there are a few little gotchas, like the license
server problems). Rewriting an existing app as a browser-based
application and setting up ASP hosting (which depends on the
incredibly insecure IIS) is going to cost far, far more than
implementing a brand-new Terminal Server, and you're going to lose
functionality and ease of use for very little gain in the way of
administrative centralization and client independence.
There network solutions are slow, so, correct me if I'm wrong, but
wouldn't a terminal services solution where the Access front end
and the SQL Server backend are located on the same server provide
relatively fast response. . . .
As long as the connection is not so slow that it causes lags in
terminal window response. Given that Remote Desktop works usably
over dialup, that would have to be an extremely slow network
connection.
. . . Do
you think it would be faster than an ASP front end?


That's not really a comparable question. A properly designed ASP
front end will be as responsive as any browser-based application,
but all browser-based applications have limitations in comparison to
desktop apps because:

1. the widgets are much more primitive and the events much less
plentiful, AND

2. web apps are stateless. That is, all web apps are basically like
unbound forms in Access.

Both of these have enormous repercussions for user interface design.
You can't just port your Access screens directly to an ASP app --
almost all processes have to be redesigned from scratch to work the
way browser-based apps work.

This kind of thing is very difficult for someone who is accustomed
to programming in Access. I still have major problems designing
browser-based interfaces (I use PHP), because I have to abandon all
my Access-developed instincts for how to model processes and
implement user interaction.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 12 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.