Converting app to ASP?

#1

A company that I'm doing a couple of projects for have a main
application written in Access for their production side. It maintains
the employee and customer tables and schedules their technicians.

Their reports are written to Excel, not using the report writer. If
they used a report writer the reports would take a few seconds to
process but they pass the report on to the clients and not all of their
clients may have Access but would have Excel.

They want to port the application to SQL server. And then convert the
application to the web using ASP.Net. They say the current system bogs
down when they have around 20 users on the system. I noticed in the
past that a key user of the application has less than 500K memory so
perhaps delay is from the memory, not the app. The user can't open up
multiple copies of the app, maybe run a report in the background while
working in another copy probably due to the memory limitations.

Will converting the application to ASP make it faster? Would it be a
major undertaking or are there programs that can make the designing of
the app in ASP a simple process?

#2

Salad wrote:

Quote:

A company that I'm doing a couple of projects for have a main
application written in Access for their production side. It maintains
the employee and customer tables and schedules their technicians.

Their reports are written to Excel, not using the report writer. If
they used a report writer the reports would take a few seconds to
process but they pass the report on to the clients and not all of their
clients may have Access but would have Excel.

They want to port the application to SQL server. And then convert the
application to the web using ASP.Net. They say the current system bogs
down when they have around 20 users on the system. I noticed in the
past that a key user of the application has less than 500K memory so
perhaps delay is from the memory, not the app. The user can't open up
multiple copies of the app, maybe run a report in the background while
working in another copy probably due to the memory limitations.

Will converting the application to ASP make it faster? Would it be a
major undertaking or are there programs that can make the designing of
the app in ASP a simple process?

Converting to ASP means a complete rewrite.

Is it that all users on the system slow down when there are about 20
users on the system or is it just the one user you mention. 500K memory
is insufficient. They need more!!

Bob

#3

Bob Alston wrote:

Quote:

Salad wrote:

A company that I'm doing a couple of projects for have a main
application written in Access for their production side. It maintains
the employee and customer tables and schedules their technicians.

Their reports are written to Excel, not using the report writer. If
they used a report writer the reports would take a few seconds to
process but they pass the report on to the clients and not all of
their clients may have Access but would have Excel.

They want to port the application to SQL server. And then convert the
application to the web using ASP.Net. They say the current system
bogs down when they have around 20 users on the system. I noticed in
the past that a key user of the application has less than 500K memory
so perhaps delay is from the memory, not the app. The user can't open
up multiple copies of the app, maybe run a report in the background
while working in another copy probably due to the memory limitations.

Will converting the application to ASP make it faster? Would it be a
major undertaking or are there programs that can make the designing of
the app in ASP a simple process?

Converting to ASP means a complete rewrite.

Is it that all users on the system slow down when there are about 20
users on the system or is it just the one user you mention. 500K memory
is insufficient. They need more!!

Bob

I really don't know if all users are slow within the app. I know that
the user I mentioned is a key user. Why she has a slow computer is
beyond me. Thanks for your input.

#4

Albert D. Kallal wrote:

Quote:

Salad" <salad (AT) oilandvinegar (DOT) com> wrote in message
news:Pv2dncQMSK2JQCXWnZ2dnUVZ_uCdnZ2d (AT) earthlink (DOT) com...

A company that I'm doing a couple of projects for have a main
application written in Access for their production side. It maintains
the employee and customer tables and schedules their technicians.

Their reports are written to Excel, not using the report writer. If
they used a report writer the reports would take a few seconds to
process but they pass the report on to the clients and not all of
their clients may have Access but would have Excel.

Any particular reason why some format like PDF is not being used? There
several free PDF solutions, and for access 2007, PDF support is natively
built in without even adding any third party tools or downloads
(assuming you have office sp2 or later).

This app wasn't written or modified by me. If one could do a table of
contents in a PDF that would jump to a page, that probably would be OK.
Typically, a schedule will have around 30 worksheets in a month; 1 per
day, and all schedules for a day in one worksheet. It's simply clicking
a tab to see what is going on. In an MS Access report, the processing
takes a couple of seconds. Writing to Excel takes longer due to the
format...one can't write them in a group, that'd be nice, and it's
simply due to the layout and formatting of the report. I think if one
could write a TOC in a PDF or have tabs like Worksheets in Excel in a
PDF that'd work.

Quote:

They want to port the application to SQL server. And then convert the
application to the web using ASP.Net.

Ok, so they are talking about about dumping ms-access.

Yes.

Development in

Quote:

.net is significantly more expensive. On the other hand if those
developers are really talented developers then they might be able to
offset some of those increased costs. However, I know of many companies
that by decree from some department state that they don't want to use
Access anymore because it doesn't perform well or they have trouble
supporting the application. They then turned to .net, and realize how
much more expensive it can be.

I think they got a new IT person in. He has determined SQL Server and

ASP is the way to go. He's got the company ear, I don't.

Quote:

They say the current system bogs down when they have around 20 users
on the system. I noticed in the past that a key user of the
application has less than 500K memory so perhaps delay is from the
memory, not the app. The user can't open up multiple copies of the
app, maybe run a report in the background while working in another
copy probably due to the memory limitations.

In every application I have ever looked at, the vast majority of
performance is that of good designs vs that of bad designs. We see
weekly posts in the SQL server newsgroups that when people move their
data from an access backend to that of SQL server, the performance
actually slows down. On the other hand, if you know how to use SQL
server properly, then SQL server will generally run absolute circles and
beat the pants off an access database runnong over an network if you
know what you are doing.

It seems to work quickly the times I've seen it in action. The only
complaint I've heard on speed is the processing of reports...the writing
to Excel. I've heard the reports take about 3 hours (not one, a bunch)
to process each day. And they gave the key player a machine that can't
load multiple copies of Access (at least so she says) and she has less
than 1/2 meg of memory (quite a lot if we were still in DOS, not so much
in Windows).

Quote:

Will converting the application to ASP make it faster?

Well, it doesn't make it faster unless the people who are writing the
application know what the heck they are doing. I once asked an 80 year
old grandmother if it makes any sense for an instant teller machine to
download every single bank account into the machine, AND THEN you type
in your bank account you want to work on? I don't think anybody with
with any sensible developers deals but think that an instant teller
should download everything first and then ask what account number to
work on. Obviously the approach here is to ask the user to type in
their account number, and then pull down one record. On the other hand
while everybody can see the obvious solution here, when going to Access,
I see application after application where forms are bound to large
tables without any type of where clause when they those forms are being
launched. I guess I'm saying if a 80 year old grandmother can come up
with better software designs that supposedly access developer who is
being paid to do work, then we have a serious problem here don't we?

I spend this concept of searching + user interface + reducing your
bandwidth requirements in the following little article of mine:

http://www.members.shaw.ca/AlbertKal...rch/index.html

Would it be a major undertaking or are there programs that can make
the designing of the app in ASP a simple process?

Well if you mean that they are re-developing the application from
scratch? Yes, they are. There's no special automated solution here.
However, often the greatest value in any application built is all the
business requirements and gathering and building something that the
employees need. That information been gathered over time and now
obviously is a success for this organization, and you've also proven the
need for this business process. Often a company hires expensive
developers, they build something, and in fact in almost eight of 10
cases, they don't use the resulting product that built. So proof of
concept prototyping, and gathering the business requirements is often
the most significant work you do in a software development cycle.

Thus, the real value of your application is that it shows and proves
design and need for that business process within their organization.
However because you don't have the other skill sets, you're not going to
benefit from that proof of concept that you've just done for them, are
you? And worse is those other technologies likely have a much higher
billing rate in the marketplace.

In your situation, what I would do is move the back end to SQL server.
That would allow you to continue to use the front end as you have now.
As a general rule if your application is well written then the amount of
work to move the backend data to SQL server is very small. I've taken
some pretty large Access applications, and had them up in running in
just a day of time. The other beauty of this approach is that you keep
your current business application running, and likely 98% or more of
your testing application will run without modifications. However what
this means then is your data is now sitting on SQL server, and they can
use some web based reporting system for the data. The other issues you
have scalability and can run 40 users without problems, or you can have
the website hit and pull data from this application now.

Also keep in mind that you don't develop forms in SQL server. So if you
move your data to SQL server, then you still have to write the code
somewhere, such as using .net, asp.net web stuff, or even ms-access as
the front end as you have now.

Also SQL server is very easy to get into, and there's lots of free
eddition you can download to play with and learn. I'd never use SQL
server before, and well under 2 hours I had some pretty nice stuff up
and running pretty quick. As a general rule, just learning to setup and
use tables on SQL server is far less time and far less of a learning
curve than learning how to use ms access for example.

On the other hand, perhaps they are running SharePoint? As you know for
Access 2010 it has the ability to create web based applications.

Yes. I've very impressed with your app. But they don't use SharePoint.
I'd want to check out Office 2010 first; port the app to A2010 and
provide some web parts; reporting, to it. It'd be cheaper. But they
are impressed with their IT guy. Maybe they won't be as impressed if
they get a big bill and not the gratification they seek.

Quote:

So maybe a WEB based solution built with the easy to use product called
ms access that you already know is a possibility here?

I won't fight against their IT guy. I'm just a developer, he has the
power. I think the company will be impressed with their bill for the
upgrade. They've been tightfisted financially in my7 experience, this
should be an interesting experience for them.

Quote:

I don't think 20 users in an application is too many, but if you've not
paid attention to make your application perform very well, then that's
an issue you might want to address.

Not my app. Like I said, the only thing I saw (heard from key user)
that was slow was the reporting process. I told her a $20/memory
upgrade would help her a lot. The company said no to her in buyting her
new memory, she won't buy it herself, so the bottom line is she'll
remain frustrated until the new app comes in and the company will take
on a large bill.

#5

On Sun, 04 Apr 2010 14:26:33 -0700, Salad <salad (AT) oilandvinegar (DOT) com>
wrote:

Some problems can MUCH better be fixed by Dell than by expensive
consultants. Can you bring in a fast computer for one day for her to
work on?

BTW, it is always worth doing a real-world test. I recently guessed
that a hybrid VB6 + .NET WinApp on 6 year old hardware would benefit
from boosting memory from 1GB to 2GB. We temporarily took the memory
from one machine and added it to another and re-ran our tests: only a
very minor performance benefit.

-Tom.
Microsoft Access MVP

Quote:

Bob Alston wrote:
Salad wrote:

A company that I'm doing a couple of projects for have a main
application written in Access for their production side. It maintains
the employee and customer tables and schedules their technicians.

Their reports are written to Excel, not using the report writer. If
they used a report writer the reports would take a few seconds to
process but they pass the report on to the clients and not all of
their clients may have Access but would have Excel.

They want to port the application to SQL server. And then convert the
application to the web using ASP.Net. They say the current system
bogs down when they have around 20 users on the system. I noticed in
the past that a key user of the application has less than 500K memory
so perhaps delay is from the memory, not the app. The user can't open
up multiple copies of the app, maybe run a report in the background
while working in another copy probably due to the memory limitations.

Will converting the application to ASP make it faster? Would it be a
major undertaking or are there programs that can make the designing of
the app in ASP a simple process?

Converting to ASP means a complete rewrite.

Is it that all users on the system slow down when there are about 20
users on the system or is it just the one user you mention. 500K memory
is insufficient. They need more!!

Bob

I really don't know if all users are slow within the app. I know that
the user I mentioned is a key user. Why she has a slow computer is
beyond me. Thanks for your input.

#6

On Apr 4, 5:52*pm, Salad <sa... (AT) oilandvinegar (DOT) com> wrote:

Quote:

Albert D. Kallal wrote:

Salad" <sa... (AT) oilandvinegar (DOT) com> wrote in message
news:Pv2dncQMSK2JQCXWnZ2dnUVZ_uCdnZ2d (AT) earthlink (DOT) com...

A company that I'm doing a couple of projects for have a main
application written in Access for their production side. *It maintains
the employee and customer tables and schedules their technicians.

Their reports are written to Excel, not using the report writer. *If
they used a report writer the reports would take a few seconds to
process but they pass the report on to the clients and not all of
their clients may have Access but would have Excel.

Any particular reason why some format like PDF is not being used? *There
several free PDF solutions, and for access 2007, PDF support is natively
built in without even adding any third party tools or downloads
(assuming you have office sp2 or later).

This app wasn't written or modified by me. *If one could do a table of
contents in a PDF that would jump to a page, that probably would be OK.
* Typically, a schedule will have around 30 worksheets in a month; 1 per
day, and all schedules for a day in one worksheet. *It's simply clicking
a tab to see what is going on. *In an MS Access report, the processing
takes a couple of seconds. *Writing to Excel takes longer due to the
format...one can't write them in a group, that'd be nice, and it's
simply due to the layout and formatting of the report. *I think if one
could write a TOC in a PDF or have tabs like Worksheets in Excel in a
PDF that'd work.

They want to port the application to SQL server. *And then convert the
application to the web using ASP.Net.

Ok, so they are talking about about dumping ms-access.

Yes.

* Development in> .net is significantly more expensive. On the other hand if those
developers are really talented developers then they might be able to
offset some of those increased costs. *However, I know of many companies
that by decree from some department state that they don't want to use
Access anymore because it doesn't perform well or they have trouble
supporting the application. *They then turned to .net, and realize how
much more expensive it can be.

I think they got a new IT person in. *He has determined SQL Server and
ASP is the way to go. *He's got the company ear, I don't.

They say the current system bogs down when they have around 20 users
on the system. *I noticed in the past that a key user of the
application has less than 500K memory so perhaps delay is from the
memory, not the app. The user can't open up multiple copies of the
app, maybe run a report in the background while working in another
copy probably due to the memory limitations.

In every application I have ever looked at, the vast majority of
performance is that of good designs vs that of bad designs. *We see
weekly posts in the SQL server newsgroups that when people move their
data from an access backend to that of SQL server, the performance
actually slows down. On the other hand, if you know how to use SQL
server properly, then SQL server will generally run absolute circles and
beat the pants off an access database runnong over an network if you
know what you are doing.

It seems to work quickly the times I've seen it in action. *The only
complaint I've heard on speed is the processing of reports...the writing
to Excel. *I've heard the reports take about 3 hours (not one, a bunch)
to process each day. *And they gave the key player a machine that can't
load multiple copies of Access (at least so she says) and she has less
than 1/2 meg of memory (quite a lot if we were still in DOS, not so much
in Windows).

Will converting the application to ASP make it faster?
Well, it doesn't make it faster unless the people who are writing the
application know what the heck they are doing. *I once asked an 80 year
old grandmother if it makes any sense for an instant teller machine to
download every single bank account into the machine, AND THEN you type
in your bank account you want to work on? *I don't think anybody with
with any sensible developers deals but think that an instant teller
should download everything first and then ask what account number to
work on. *Obviously the approach here is to ask the user to type in
their account number, and then pull down one record. *On the other hand
while everybody can see the obvious solution here, when going to Access,
I see application after application where forms are bound to large
tables without any type of where clause when they those forms are being
launched. *I guess I'm saying if a 80 year old grandmother can come up
with better software designs that supposedly access developer who is
being paid to do work, then we have a serious problem here don't we?

I spend this concept of searching + user interface + reducing your
bandwidth requirements in the following little article of mine:

http://www.members.shaw.ca/AlbertKal...rch/index.html

Would it be a major undertaking or are there programs that can make
the designing of the app in ASP a simple process?

Well if you mean that they are re-developing the application from
scratch? Yes, they are. *There's no special automated solution here.
However, often the greatest value in any application built is all the
business requirements and gathering and building something that the
employees need. That information been gathered over time and now
obviously is a success for this organization, and you've also proven the
need for this business process. Often a company hires expensive
developers, they build something, and in fact in almost eight of 10
cases, they don't use the resulting product that built. *So proof of
concept prototyping, and gathering the business requirements is often
the most significant work you do in a software development cycle.

Thus, the real value of your application is that it shows and proves
design and need for that business process within their organization. *
However because you don't have the other skill sets, you're not going to
benefit from that proof of concept that you've just done for them, are
you? *And worse is those other technologies likely have a much higher
billing rate in the marketplace.

In your situation, what I would do is move the back end to SQL server.
That would allow you to continue to use the front end as you have now. *
As a general rule if your application is well written then the amount of
work to move the backend data to SQL server is very small. *I've taken
some pretty large Access applications, and had them up in running in
just a day of time. The other beauty of this approach is that you keep
your current business application running, and likely 98% or more of
your testing application will run without modifications. *However what
this means then is your data is now sitting on SQL server, and they can
use some web based reporting system for the data. *The other issues you
have scalability and can run 40 users without problems, or you can have
the website hit and pull data from this application now.

Also keep in mind that you don't develop forms in SQL server. So if you
move your data to SQL server, then you still have to write the code
somewhere, such as using .net, asp.net web stuff, or even ms-access as
the front end as you have now.

Also SQL server is very easy to get into, and there's lots of free
eddition you can download to play with and learn. *I'd never use SQL
server before, and well under 2 hours I had some pretty nice stuff up
and running pretty quick. *As a general rule, just learning to setup and
use tables on SQL server is far less time and far less of a learning
curve than learning how to use ms access for example.

On the other hand, perhaps they are running SharePoint? As you know for
Access 2010 it has the ability to create web based applications.

Yes. *I've very impressed with your app. *But they don't use SharePoint.
* I'd want to check out Office 2010 first; port the app to A2010 and
provide some web parts; reporting, to it. *It'd be cheaper. *But they
are impressed with their IT guy. *Maybe they won't be as impressed if
they get a big bill and not the gratification they seek.

So maybe a WEB based solution built with the easy to use product called
ms access that you already know is a possibility here?

I won't fight against their IT guy. *I'm just a developer, he has the
power. *I think the company will be impressed with their bill for the
upgrade. *They've been tightfisted financially in my7 experience, this
should be an interesting experience for them.

I don't think 20 users in an application is too many, but if you've not
paid attention to make your application perform very well, then that's
an issue you might want to address.

Not my app. *Like I said, the only thing I saw (heard from key user)
that was slow was the reporting process. *I told her a $20/memory
upgrade would help her a lot. *The company said no to her in buyting her
new memory, she won't buy it herself, so the bottom line is she'll
remain frustrated until the new app comes in and the company will take
on a large bill.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

If the IT guy wants to move to sqlServer, you can do that and point
the ms-access application to it

as to reports, could you not use access2010 to build a web-report that
will deploy on a local desktop without using sharepoint ?

how are they building excel worksheet, using excel automation ?
creating an xml / html text file ?

using excel automation is slow, creating a text file is much faster

#7

Roger wrote:

Quote:

If the IT guy wants to move to sqlServer, you can do that and point
the ms-access application to it

That could be done. I don't know if that would improve the speed of the
application.

Quote:

as to reports, could you not use access2010 to build a web-report that
will deploy on a local desktop without using sharepoint ?

I think so but the files aren's just for internal use but for the
external clients as well/

Quote:

how are they building excel worksheet, using excel automation ?
creating an xml / html text file ?

Using automation.

Quote:

using excel automation is slow, creating a text file is much faster

I know. Creating the report thru the Access report writer is extremely
quick. I think they like just hitting a worksheet tab in Excl and
viewing the daily data per worksheet instead of scrolling thru pages and
pages of a report. I doubt they'll get that flexibility using ASP either.

#8

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in
news:cN5un.26498$3D3.2152 (AT) newsfe19 (DOT) iad:

Quote:

As a general rule, just learning to setup and use tables on SQL
server is far less time and far less of a learning curve than
learning how to use ms access for example.

It's a piece of cake if you already know how to build tables and
design schemas from working with Access.

Otherwise, not so much.

That is, I think you're underrating the amount of knowledge and
experience you already had under your belt in regard to database
design when you first started working with SQL Server.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

#9

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote in message

Quote:

Anyway, this is why I fight the good fight on StackOverflow.com and
elsewhere, meeting Access bigotry with facts wherever I see it.

I suspect that you're not interested in a Ford versa Chevy type discussion
at all (we got over that kind of thing in grade school). However, when
criticism becomes unfair it can have a real bottom line effect on adoption
and use of product that I have a considerable amount of investment into.
Including a number of products that are sold not as being Access based, but
simply as a solution into particular marketplaces. How IT views access can
thus really affect my bottom line.

Access has its warts and problems like any product, and I don't mind
criticisms of shortcomings, I really don't. However, when people dump on it
because they don't understand the product, then that's when I raise my hand.
I often let things go in this NG. On StackOverflow I tend to be quite a bit
harsher, because there's more developers there.

In the newsgroups here, we're often helping new and frustrated users, and
they just trying to get some work done. They don't know a lot about other
products. On stackoverflow, it's full of developers, and that criticism is
often unfair.

Quote:

A2010 is going to be huge in that regard, and I can't wait -- I have
at least two clients for whom it could be a huge win, in fact, and I
intend to start experimenting and prototyping as soon as I can
download the Office 2010 RTM from MSDN!

I really like some of the aspects of the new system (I sure you figured that
out!!). From an early point on, I actually liked and embraced the idea
SharePoint is a good thing to be a part of. I think it's important to note,
that for organizations that have SharePoint, and they tend to be the ones
with good money, this opens up a lot of doors for Access and Access
developers. And it also opens up the doors for access to be adopted again
in corporate environments where might not have been. And for the first time
in probably 15 years, there's even a video posting on the Access blog where
Microsoft is internally using some Access applications build. This is great
news.

However, for public facing WEB based applications in environments where
customers don't have SharePoint? Then I think this issue has a lot more
serious downsides. I as a general rule can't just go to a customer and sell
them SharePoint for ONLY a few web based forms, and while hosting is an
option, it's not a great option for anonymous users.

The result here is I am not really sure if I will ever wind building
applications for the WEB that are "public" facing with access. On the other
hand I had a good conversation with the folks at www.Accesshosting.com. I
stated to them that it is VERY much worth it for them to try hard to give
anonymous usage and to eliminate the need to log into any website we build.

They already came back to me and said they believe they have a working
solution for me. And to be fair, SharePoint itself is receiving major
upgrades and benefits to better support public facing web sites with
SharePoint 2010. However the design philosophy and idea of an anonymous web
site is not really for all those cool SharePoint workflow and other features
such as Access web stuff.

Of course the problem here is the philosophy behind Access is not designed
around you having to build and set up your own user logons. when using the
SharePoint logon system, then everything's fantastic.

One of the great things about the new asp.net tools is it assumes and
realizes that most developers are going to have to setup and build some type
of user logon system on a web site. Therefore it comes with a whole bunch of
wizards and setups to make this really easy. And they've even tided into
the user security roles when you're using SQL server. This also enables you
to set up things such as having certain buttons and things disabled on
particular web parts with GREAT ease. Again it just comes down to the
philosophy of design from the early days, and what the average user is going
to be doing with an asp.net web site.

Because the user authentication, and sign up in Access WEB is totally based
around the SharePoint setup, then this is really great as it frees you from
having to bother with this issue for each little WEB based application you
write and deployed within the organization. So in this type of scenario,
being married to SharePoint is really great.

The above issue is just like how VB6 was good for un-bound forms because
they had tons and tons of wizards that would help you build and connect to
data. However when you come from VB6 and you jump into Access development,
and you start trying to build all your forms as unbound, you get the worst
of both worlds, because Access doesn't have tons and tons of wizards to try
and help you work with un-bound forms. And, even worse is that our bound
forms has a huge number of events and features setup around the idea and
concept of bound forms. If you go un-bound in Access, you have to give up
most of those features + not having wizards + support tools.

The above is not a huge deal. However, the above points out why Access for
the web is somewhat weak in terms of setting something up and having to
build your own logon system. With asp.net there's a great set of wizards and
wide sweeping support that permeates through the whole development process
because most developers know when they're building a website, they going to
have some type of logon system. I can't think of any usable web application
that doesn't have some type of log on system.

What's interesting, is I think for a lot of types of applications, the
Access WEB development system is actually the best and quickest development
tool for SharePoint applications - it's the first real RAD WEB based tool
for SharePoint. I also think what's really fascinating is that the Access
application can be set up as a SharePoint "template" that people throughout
the organization can use to create a web site for their own purpose based on
that application (the Access web application in fact becomes a whole little
website or so called sub-site when you do this on SharePoint).

I am kind of at a crossroads here:

For SharePoint environments, Access is a winner. No question.

For public facing WEB type stuff, I'm really torn here. I'm not really sure
it makes a lot of sense to build a logon system in access WEB. If the folks
at Access hosting come up with fairly affordable monthly rate, then yes I
will spend a day building some type of logon system with all the little
logon forms and the "I forgot my password" email me stuff. However if
they're not really affordable rates, then I stick to using Access WEB for
SharePoint customers, or using Access hosting for those customers that still
have internal staff and logons are required and controlled by the staff for
their organization itself.

However, for public facing web sites where the customers can create and
setup their own login and signup process? Right now, my bets are that I
will be using asp.net for this type of application.

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

#10

On Apr 5, 10:15*am, Salad <sa... (AT) oilandvinegar (DOT) com> wrote:

Quote:

Roger wrote:

If the IT guy wants to move to sqlServer, you can do that and point
the ms-access application to it

That could be done. *I don't know if that would improve the speed of the
application.

as to reports, could you not use access2010 to build a web-report that
will deploy on a local desktop without using sharepoint ?

I think so but the files aren's just for internal use but for the
external clients as well/

how are they building excel worksheet, using excel automation ?
creating an xml / html text file ?

Using automation.

using excel automation is slow, creating a text file is much faster

I know. *Creating the report thru the Access report writer is extremely
quick. *I think they like just hitting a worksheet tab in Excl and
viewing the daily data per worksheet instead of scrolling thru pages and
pages of a report. *I doubt they'll get that flexibility using ASP either.

moving the application to sqlServer may or may not improve
performance, but it does
give the IT guy the perception of a 'win' on his check list

give you another tool to optimize linked views if performance is an
issue

it seems that part of the app is slow due to the creation of
internal / external worksheets due to automation. If you saved one of
the worksheets as an xml document, and then changed the creation
process to create text based, xml-document, would that improve that
portion of the creation process enough for it to become a non issue ?