Porting Access DB to a Web Application

#1

I have a client who wishes to port his Access DB to a Web
Application. His application currently does everything he needs,
receiving, invoicing, shipping, repair notes, tracking, etc.

In case I get stuck in porting it into a web app. (BTW customers need
to create Work Orders and track the entire status). Is there anyone
out there that would be willing to help out on the project? If so,
how much would you charge per hour to help out? I think there are
probably 50+ forms, 50+ reports, and about 20-+50 tables.

Please reply via email to cubangeek (AT) gmail (DOT) com or you can call me at
818-795-1024

#2

On Tue, 21 Jun 2011 19:56:38 -0700 (PDT), cubangeek
<cubangeek (AT) gmail (DOT) com> wrote:

Quote:

I have a client who wishes to port his Access DB to a Web
Application. His application currently does everything he needs,
receiving, invoicing, shipping, repair notes, tracking, etc.

In case I get stuck in porting it into a web app. (BTW customers need
to create Work Orders and track the entire status). Is there anyone
out there that would be willing to help out on the project? If so,
how much would you charge per hour to help out? I think there are
probably 50+ forms, 50+ reports, and about 20-+50 tables.

I would suggest porting to a web application just the functionality
that the external customers require. Leave everything else in Access.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

#3

On Wed, 22 Jun 2011 11:38:35 -0600, Tony Toews
<ttoews (AT) telusplanet (DOT) net> wrote:

Quote:

On Tue, 21 Jun 2011 19:56:38 -0700 (PDT), cubangeek
cubangeek (AT) gmail (DOT) com> wrote:

I have a client who wishes to port his Access DB to a Web
Application. His application currently does everything he needs,
receiving, invoicing, shipping, repair notes, tracking, etc.

In case I get stuck in porting it into a web app. (BTW customers need
to create Work Orders and track the entire status). Is there anyone
out there that would be willing to help out on the project? If so,
how much would you charge per hour to help out? I think there are
probably 50+ forms, 50+ reports, and about 20-+50 tables.

I would suggest porting to a web application just the functionality
that the external customers require. Leave everything else in Access.

Tony

How would one get something in and out of an Access MDB to and from
the web Tony? What would the web app front and back end be written in?

We have requests to have reservations be made on the web and then have
those imported into our Access MDB, in addition to uploading
availibility to the web. And some clients want to be able run our app
on the web (I am not sure if it's all of it but then there's reporting
to consider).

I don't understand how we can accomplish this with a desktop Access
system.

-paulw

#4

"PW" wrote in message news:0lp407p42m99b6nfuhlvvdh3m2bslce28m (AT) 4ax (DOT) com...

Quote:

How would one get something in and out of an Access MDB to and from
the web Tony? What would the web app front and back end be written in?

We have requests to have reservations be made on the web and then have
those imported into our Access MDB, in addition to uploading
availibility to the web. And some clients want to be able run our app
on the web (I am not sure if it's all of it but then there's reporting
to consider).

I don't understand how we can accomplish this with a desktop Access
system.

-paulw

Actually quite a few ways to do this.

First of all, a very good number of web providers allow external connections
by ODBC to their SQL server. That same database engine will be used to feed
and run your web based application part. And thus Access can link to that
external data source and utilize the information from that web site.

Another way to accomplish this is to consider access 2010 and web services.
However when talking about a customer portal were you need users to self
signup and create their own logon IDs, then access web services is probably
not appropriate. On the other hand if you're building a system in which
users are from your company, and can logon to the system, then you certainly
can consider Access web services (available in office 365).

If you take a look the following video of mine, notice that the halfway
Point I switch to running the access application running 100% inside of a
browser:

http://www.youtube.com/watch?v=AU4mH0jPntI

The above application was 100% written using MS Access 2010.

So even access itself can create web based portions of applications. The
other portions of the applications can remain your classic longtime VBA
parts. As noted with the upcoming office 365, it's a piece a cake to create
a few web based forms in Access 2010, and allow your users to enter data
into those forms and then pull the data down from the web to your client
version of Access. And as I stress in the case of Access Web Services, the
technically building of forms and throwing them up on the web is dead easy.
The REAL technological challenges are things like security, and what type of
user base and signup issues you're going to encounter. If you don't resolve
or consider those signup issues and membership and logons and issuing
customer IDs, then for a lot of applications it means that Access Based Web
services is not appropriate. In other words, for public facing web sites,
Access Web not really applicable.

However if you do need to create new "external" user logons etc, then
ASP.net + SQL server and the standard .net tools will allow you to create
such systems. And thus you built just the web part, and then as long as the
web provider allows external connections to the SQL server, then it's a
simple matter to every once in awhile pull down the reservations at the end
of the day into Access. And in some cases, you can have your client desktop
application directly use the data in the web based systems. So, you can link
"some" tables to the web, and have other tables local.

This idea of a hybrid approach to an application makes a lot of sense.

I also talk at length about some considerations between improving
connectivity for your applications, and in fact you really do need to go
down the road of web based applications in the following article of mine.
http://www.kallal.ca/Toweb/Index.html

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

#5

Tony Toews <ttoews (AT) telusplanet (DOT) net> wrote in
news:n3a4071as82tb8374tbej06hrcvoo870il (AT) 4ax (DOT) com:

Quote:

On Tue, 21 Jun 2011 19:56:38 -0700 (PDT), cubangeek
cubangeek (AT) gmail (DOT) com> wrote:

I have a client who wishes to port his Access DB to a Web
Application. His application currently does everything he needs,
receiving, invoicing, shipping, repair notes, tracking, etc.

In case I get stuck in porting it into a web app. (BTW customers
need to create Work Orders and track the entire status). Is there
anyone out there that would be willing to help out on the project?
If so, how much would you charge per hour to help out? I think
there are probably 50+ forms, 50+ reports, and about 20-+50
tables.

I would suggest porting to a web application just the
functionality that the external customers require. Leave
everything else in Access.

Let me second this recommendation.

As part of the process, it would likely be a good idea to upsize the
back end to a database that is appropriate for a web application,
such as SQL Server of MySQL.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#6

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in
news:5YtMp.14956$PA5.3118 (AT) newsfe01 (DOT) iad:

Quote:

a very good number of web providers allow external connections
by ODBC to their SQL server.

But a very large number of the inexpensive hosting packages do NOT
support this kind of access. External connections will generally
cost you more money, and really can only be done properly over a
VPN.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

#7

On Wed, 22 Jun 2011 16:24:02 -0600, "Albert D. Kallal"
<PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote:

Quote:

"PW" wrote in message news:0lp407p42m99b6nfuhlvvdh3m2bslce28m (AT) 4ax (DOT) com...

How would one get something in and out of an Access MDB to and from
the web Tony? What would the web app front and back end be written in?

We have requests to have reservations be made on the web and then have
those imported into our Access MDB, in addition to uploading
availibility to the web. And some clients want to be able run our app
on the web (I am not sure if it's all of it but then there's reporting
to consider).

I don't understand how we can accomplish this with a desktop Access
system.

-paulw

Actually quite a few ways to do this.

First of all, a very good number of web providers allow external connections
by ODBC to their SQL server. That same database engine will be used to feed
and run your web based application part. And thus Access can link to that
external data source and utilize the information from that web site.

Another way to accomplish this is to consider access 2010 and web services.
However when talking about a customer portal were you need users to self
signup and create their own logon IDs, then access web services is probably
not appropriate. On the other hand if you're building a system in which
users are from your company, and can logon to the system, then you certainly
can consider Access web services (available in office 365).

If you take a look the following video of mine, notice that the halfway
Point I switch to running the access application running 100% inside of a
browser:

http://www.youtube.com/watch?v=AU4mH0jPntI

The above application was 100% written using MS Access 2010.

So even access itself can create web based portions of applications. The
other portions of the applications can remain your classic longtime VBA
parts. As noted with the upcoming office 365, it's a piece a cake to create
a few web based forms in Access 2010, and allow your users to enter data
into those forms and then pull the data down from the web to your client
version of Access. And as I stress in the case of Access Web Services, the
technically building of forms and throwing them up on the web is dead easy.
The REAL technological challenges are things like security, and what type of
user base and signup issues you're going to encounter. If you don't resolve
or consider those signup issues and membership and logons and issuing
customer IDs, then for a lot of applications it means that Access Based Web
services is not appropriate. In other words, for public facing web sites,
Access Web not really applicable.

However if you do need to create new "external" user logons etc, then
ASP.net + SQL server and the standard .net tools will allow you to create
such systems. And thus you built just the web part, and then as long as the
web provider allows external connections to the SQL server, then it's a
simple matter to every once in awhile pull down the reservations at the end
of the day into Access. And in some cases, you can have your client desktop
application directly use the data in the web based systems. So, you can link
"some" tables to the web, and have other tables local.

This idea of a hybrid approach to an application makes a lot of sense.

I also talk at length about some considerations between improving
connectivity for your applications, and in fact you really do need to go
down the road of web based applications in the following article of mine.
http://www.kallal.ca/Toweb/Index.html

Thanks Albert et al. I don't want to have to pay $50 grand or
whatever for a total rewrite (.NET or whatever) in a market that I
don't think will pay for it or support it. We've tried that before and
besides, our software is custom. No two versions are exactly the
same.

-paulw

#8

On 22 Jun 2011 23:11:36 GMT, "David-W-Fenton"
<NoEmail (AT) SeeSignature (DOT) invalid> wrote:

Quote:

I would suggest porting to a web application just the
functionality that the external customers require. Leave
everything else in Access.

Let me second this recommendation.

As part of the process, it would likely be a good idea to upsize the
back end to a database that is appropriate for a web application,
such as SQL Server of MySQL.

Agreed. I should've posted that. And that would've been the first
stage. Then webifying the necessary portions. (Hows that for
mangling English?)

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

#9

On Thu, 23 Jun 2011 15:05:42 -0600, Tony Toews
<ttoews (AT) telusplanet (DOT) net> wrote:

Quote:

On 22 Jun 2011 23:11:36 GMT, "David-W-Fenton"
NoEmail (AT) SeeSignature (DOT) invalid> wrote:

I would suggest porting to a web application just the
functionality that the external customers require. Leave
everything else in Access.

Let me second this recommendation.

As part of the process, it would likely be a good idea to upsize the
back end to a database that is appropriate for a web application,
such as SQL Server of MySQL.

Agreed. I should've posted that. And that would've been the first
stage. Then webifying the necessary portions. (Hows that for
mangling English?)

Tony

Can SQL Server Express be used for real applications? I am not sure
the time and money spent on SQL Server for us (and the hosting cost)
would be worth it with our clientele base (I know, expand it!).

-pw

#10

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access

"PW" <emailaddyinsig (AT) ifIremember (DOT) com> wrote

Quote:

Can SQL Server Express be used for real applications?

Yes, it can. However, you should not expect the capacity, responsiveness,
and security of an Enterprise SQL Server installation, tended by a staff of
"platform specialists" and DBAs in a secure data center. I've done "real
applications" in the past, using small ODBC=compliant server databases that
didn't begin to measure up to SQL Server Express, which served my clients
very well.

Quote:

I am not sure the time and money spent on SQL Server
for us (and the hosting cost) would be worth it with our
clientele base (I know, expand it!).

Read Albert's comments on hosting packages with remote server access
included.

It has always been a strong point of Access that it can work, and work well,
with so many different server databases.

--
Larry Linson, Microsoft Office Access MVP