[AccessD] Zoho Access Migration Plugin

Some responses:

Mark Simms:
>John - that is the key problem in my mind.
>I don't think I've met very many developers that knew all of these well:
>raster graphics (Photoshop), vector graphics (Illustratator), CSS,
>Javascript, HTML, XML, SQL, SQL Server, MVC Frameworks, application
servers,
>ASP.NET <http://ASP.NET>, etc, etc...

You don't need graphics to do good forms. As for XML -- it isn't hard to
understand, and the work to use an XML specification (SOAP, etc.) is the
same whether you are doing a web app or an Access-based one. We all are
comfortable with SQL, and SQL Server (or MySQL, ...) isn't that big a leap.
As for frameworks, well, you won't hear John arguing against them ;)

The truth is, a moderately competent VBA coder under Access isn't going to
have a hard time adapting to coding a web server -- sure, there is a lot of
learning curve, but once you get to the other side, it's all fairly familiar
stuff.

> Now add all of the new interactive stuff like Silverlight and it's
> mind-boggling.

Actually, when Javascript acceleration technologies mature, Silverlight,
Flash and their ilk will not have a compelling performance advantage to
offset their downsides. Firefox, Chrome, and Safari all have open-source
Javascript acceleration efforts ongoing, and convergence is inevitable.

> However, the "UI clumsy" problem is disappearing with these
> new DHTML technologies.

Agreed.

Shamil Salakhetdinov:
> What about MS ReportViewer Control and it supporting .NET
Frameworkclasslibs?
> ... (snip) ...
> I do like the latter [MS ReportViewer control/MS SQL Reporting Services]
more now...

I haven't looked at that recently. The choice of a robust reporting platform
is a critical one for any migration plans for our app, so MS SQL Reporting
Services could possibly tip the scale to a more .NET oriented approach. I
will have to re-evaluate this option.

jwcolby:
> YOU have IE as the lowest common denominator.  I have firefox
> (holding steady at about 20% worldwide).  Others have Chrome, or ...

I meant that from a web developer viewpoint. To make a standards-compliant
web page that renders well in the widest range of current browsers, you pick
a good middle ground (FireFox), and ensure your page will render acceptably
in the least-capable browser that matters to you (IE6, IE7 or IE8).

If you choose IE6 as your LCD, getting a complex page to work is painful --
expect fully 2/3 of your total page development effort to be fixing IE6 bugs
and quirks.

If you choose IE7 as your your LCD, you get a very nice increase in
standards-compliance, and far fewer bugs. Expect about 1/4 of your total
page development effort to be fixing IE7.

The IE8 story is even better. If you are willing to live with 98% of what
XHTML and CSS 2.1 can give you, using IE8 as your LCD should add almost no
real overhead in page development. You would allow a graceful (but hardly
noticeable) degradation in IE7, and provide a much plainer (but still
functional) experience in IE6.

But, you do have to sacrifice advanced HTML5 features in Firefox 3.5, and
CSS3 features in Safari -- but almost no one is using browsers with those
capabilities, so it is almost no sacrifice.

-Ken