Re: MSAccess to Web App

Hi David,

Thanks again for your comments.

Regards your comments on who owns your financial data, it's really not
that cut and dry. This isn't the forum for that discussion, of
course, but I can tell you as someone who worked in the banking
industry for decades, it's not as simple as saying "the bank owns the
data". It'd be more accurate to say that they have the data in
safekeeping, and have a significant amount of leeway in how that data
can be used, but there are many controls on how that data can be used
that require the approval of the consumer. The bank can't do whatever
it wants with the data (although they would certainly like to)

In regards to safety of online data, once again, not as simple as you
might think. In regards to financial data, for example, card
associations specify what controls must be in place in order for you
to be able accept credit card transactions online. If you don't
follow those rules, they won't process your transactions. For other
business data, while there may not be specific federal regulations in
regards to data security online, nonetheless, commercially acceptable
practices must be followed simply as a matter of good business
practice. Failure to do so can open a company to financial
liability. In today's legal environment, it could be fatal to not
invest in the necessary security measures.

There may be unethical businesses out there that would lock a customer
out of their data, but I think that they are few and far between. In
our PC-based app, for example, there are a number of ways that a user
can offload their data from our app into industry standard files that
can be used as input to other applications.

But, this is getting us away from the core question, and that has to
do with the future of the application. I think at this point, our best
strategy will be to continue to support our Access application, while
continuing work on a web-based version. Your earlier comments on
customer usage are important, and I think that we need to spend more
time understanding how our customers feel about a web app. It could
be that they'll be fine with it, over time. It could be that we'll
have to continue to support the legacy app for some time to come.
That wouldn't be the best solution for us support-wise, but we'll do
what we have to do. From a technical standpoint, I think that
regardless of marketing pronouncements, there won't be a handy-dandy
tool that will take our Access97 app and easily move it to a web
environment. There may be tools to ease the process, but I think that
we need to look at what we'll be losing in the way of new technology
if we take an older technology like Access97 and convert it directly
to the web or .Net forms, for example. It may convert, but we'll lose
new features that may or may not be important to us.

Thanks again.

Ron



On Apr 20, 3:02 pm, "David W. Fenton" <XXXuse...@xxxxxxxxxxxxxxxxxxx>
wrote:
RonG <rgaf...@xxxxxxxxxxxxx> wrote innews:01b70a4c-44c3-452d-8aa5-4485466214d7@xxxxxxxxxxxxxxxxxxxxxxxxxxx
m:

[]

Yes, there are plenty of people who don't want their data put on
someone else's server, but given the tremendous growth of Internet
banking, one would have to believe that this is becoming less and
less of a concern.

Online banking is really not in any way analogous to what you're
proposing for your app. Before online banking (either over the
Internet, or with the old dialup clients) the bank owned the data
about your accounts -- you didn't own it at all. You still don't own
the data, just the money.

But banks are regulated in a way that makes your money safe.

There is no corresponding regulation for web hosts in regard to data
safety and security, so you can't use online banking as an analogy
for trustworthiness with data.

  Not something to be ignored, but certainly not the



issue it once was.

I agree with the concern you raised about whether the userbase
would be agreeable to moving to a web-based model.  It seems to be
almost age-related across the customerbase.

Regards getting crossed off of some lists, I think that that
really varies across industries and demographics.  I'm working
with sole proprietorships for the most part. They aren't looking
for a network based application that supports lots of users, that
they can install in their office.  These are single users, for the
most part.  In that group, you'll have plenty who don't want to
deal with computers any more than they have to, and I think would
be happy with a web app, since they don't have to install
anything.  Others like the idea of having more control.  Which
group is larger, I don't know.

I believe that a web app may be the best thing for our users, but
there is the reality of support that comes into play. I don't have
a staff of programmers; I have me.  If I build to a platform that
requires a lot of support, then that's taking time away from new
development, which is where the income comes from.  In a very real
sense, I have to balance the technology needs of the users against
the business needs of my business.  I have to build something that
they want, but I also have to build something that I can support.

You also commented about a problem with a web app being that
there's no guarantee that your data actually belongs to you.  With
all due respect, I think that that's incorrect.  For one thing,
ownership of the data should be clearly stated in the licensing
for the product.

Legally, yes. But in a practical sense, if you don't actually have
the ability to, say, go into a web control panel for the database
and do a data dump any time you like, then you don't really control
it (even if you technically own it).

Personally, I would never lock a business out of their data for
non- payment of services.  That is simply unethical.  Regardless,
in the big picture, the customer's data belongs to them; I am
simply warehousing it for them as part of the ASP.

And it's not worth much without the app itself, as it's unusable.
This means that a customer who stops paying gets locked out of the
app but doesn't lose access to their data (by some mechanism?). Not
that this is of much use to them without the interface for
retrieving and editing that data.

[]

In the near term, that will probably
mean supporting both a PC-based as well as a web-based
application. There are things I can do with a PC-based app that
would be difficult to do in a web app, and vice versa.  I suppose
the best solution would be a development platform that would
support a single codebase that could be rolled out as either a web
application or as a platform- dependent app for Windows, Mac, etc.
 During my research, I did come across a platform that said it
could do this, called ActiveState Tcl. I couldn't get my hands
wrapped around whether it could actually do what it said with a
good level of quality, but that remains a possibility as well.

Anyone who is promising a single codebase for distribution on the
desktop and the web is a charlatan. The interfaces have to be
completely different, which means the desktop app will really just
be a web app running locally.

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

.

Relevant Pages

  • Re: Question for Mario Dambauer
    ... Set the flags at the system cloning tool to false, ... Best Regards, ... > configured to use a little vb app, ...
    (microsoft.public.windowsxp.embedded)
  • Re: MultiTier?
    ... I hapy with the product and support. ... My App is an ERP that is runnin 2 years with 100 concurrent usuers, ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: WMI Exception - Provider Load Failure - Enumerating Network In
    ... ..Net that have a dependency on Winlogon. ... Most likely you did not auto-resolve your Configuration dependencies, ... We have written a small test app that ... >>> Regards, ...
    (microsoft.public.windowsxp.embedded)
  • Re: Question for Mario Dambauer
    ... > Set the flags at the system cloning tool to false, ... > Best Regards, ... >> configured to use a little vb app, ...
    (microsoft.public.windowsxp.embedded)
  • Re: Custom Uninstaller and App Manager
    ... > Best regards, ... >> When I deploy my VS2003-compiled app, it installs EXEs to the desktop ... >> Remove button in the Add or Remove Programs on the Control Panel, ...
    (microsoft.public.dotnet.framework.compactframework)