Tony Toews said:
Actually the latter option may not be as difficult as doing the entire
conversion as you likely only need a few forms to be accessible by the
wireless users.
That's what we're doing - using ASP.NET to give mobile users limited access
to a subset of the data, while the Access app back on the desktop,
connecting to the server via a traditional cabled network, is used for the
more intensive data entry and reporting. It works well, and it impresses the
heck out of the clients!
I spent yesterday morning giving a demo of this
stuff. I had an Access form on my notebook running code in its Timer event
to requery a subform once a second. I'd enter a record on the Pocket PC, and
show the clients the same record appearing in the Access form on the
notebook. It was really quite simple stuff, but you should have seen the
reaction of the clients - the last time I saw anyone so excited was my
10-year-old's birthday!
That said if they are data entry forms they may have the most complex
logic behind them.
Now that we can use VB.NET or C# with ASP.NET pages, rather than VBScript as
in 'classic' ASP, and separate the code from the HTML in a 'code behind'
module, instead of having them mixed in together in the ASP page, complex
logic isn't a problem. What does cause a pretty steep learning curve though
is the differences between the controls available in ASP.NET and Access, the
different properties and events they support, and especially the very
different data access technologies. ADO.NET is something of a culture shock
to anyone familiar with 'classic' ADO, let alone to those, like me, more
familiar with DAO.
