Re: Access 2010 with Sharepoint 2010

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxxx> wrote in
news:QBqJm.2507$rE5.2452@xxxxxxxxxxxx:

"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns9CBCC354C8849f99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxx


How else can you figure out what's not going to work as well in
the browser as in Access itself? Surely you're not claiming that
100% of an Access app is going to convert to the browser-based
Sharepoint version and have exactly the same performance and ease
of use?

Well, actually, yes I kind of am making this claim.

But in other posts you're saying something completely different,
that only the forms created in Access as web forms are converted.

You certainly have to deal with increased latency, but on the
other hand since there's no data transfer down the wire, you
actually get some bonuses perofrmance also.

But the widgets in web browsers simply suck, even when extended with
AJAX.

And continuous forms? Hello?

You certanly have to choose a "web database" option for this to
happen. When you do this access will restrict your feature set to
web only features -- in fact this option even automatically
restricts the macro feature set available for you. So, for web
forms you see a reduced set of form events in the Property sheet
for example. You also see a reduced set of events that appear for
controls on your forms.

Is there any documentation anywhere describing these limitations? It
would be very useful to know that.

At that point what you build on the desktop will go up to
sharepoint exactly as it is with all of its event code, on-dirty,
on-curret code etc. All of it should/will work the same in the
browser. You have to use macro code (they added embeeded macros in
2007 but it really was for 2010!).

I've said elsewhere that I'm wary of embedded macros because of the
maintenance and auditability problems that come with them. Is there
anything that addresses this? Can you write macros that are shared
in multiple forms (i.e., not embedded) and those will be uploaded
and used appropriately? Or are you limited to the embedded macros?

And can embedded macros call things outside themselves? And, of so,
to what degree?

No question there going to be a somewhat different of an
experiance of running in an browsser, but it those differences
minor and something you'll learn after publishing a few forms.
From that point on there not really much differnce . The fidelity
and how those forms render in a browser is absolutely
stunning....nothing short of increiable..

But it's not your Access forms, but your Access *web* forms that
you're talking about. That's a crucial difference. An existing app
can't just be converted without recreating its Access forms as web
forms, correct? Or is there conversion available, such as a SAVE AS
that strips out what isn't supported (and tells you what's omitted)?

So, yes, I am saying there is almost no reason to have the server
bits running during the development process.

But have you addressed the question about the differences between
the free version available on Office Live, the pay version hosted
there, and the full Sharepoint server hosted locally? Are they
identically in functionality for a single user?

[]

Access will tell you if that database is compatible with the web.
If the web app passes the compatibility checker (and it should if
you started out developing a web only application), then it will
publish up to SharePoint).

How good is its rundown of the incompatiblities? Is it easy to work
from to get it into shape to be compatible for upload?

As I said, compared to any other web development systems, you'll
not be playing with connection strings, you'll not be playing with
HTML, you'll not be playing with some database server. You'll
simply be working with your little local access system like you've
always done.

But not with native Access forms.

Not with standard VBA.

This means it may be *similar* to Access (and thus very easy for us
to learn), but it isn't Access as we've known it and used it in the
past.

[]

Testing on all the target deployment platforms is not just a
matter of getting a thrill but a necessary part of any serious
developer's basic responsibilities.

That's true. When I build an access application now, I build and
develop the system on my machine. I as a general rule can assume
that when I deploy to the client system, it will work the same.

But you wouldn't build in A2003 for distribution on A2007 without
testing it in A2007 would you?

Likewise, you wouldn't build for Sharepoint without testing it on
the deployed version of Sharepoint.

So for web stuff, the paradigm is pretty darn similar for me. You
really can develop most if not all of your application on the
desktop before you ever attempt to publish it...

I am skeptical about all of this. I think you're elliding a lot of
the differences between standard Access in order to laud the new
platform's ability to produce Web apps easily. That's value, true,
but it's not exactly what I or my clients are looking for. I don't
have any clients who need their app deployed to run in a web browser
-- not a single one. Why would it then suddenly be valuable to them
to be able to do so?

Sure, I can think of some marginal utility coming from that
capability, but if it requires major redevelopment (as it surely
will to convert an existing Access form to an Access web form), the
cost becomes high, and if there isn't a real need for web
deployment, the cost far exceeds the benefit.

Now, for new development, sure, it could be a different balance.

But I haven't had contract for a build-from-scratch brand-new Access
app of any degree of complexity in over 5 years -- all my work now
is maintaining the apps of my existing client base, and taking on
new clients with existing apps that need to be revised, updated and
expanding. Nobody is asking for web deployment. Some have needed
remote access, but WTS takes care of that without needing to alter
the existing app in any way.

So, exciting as all these new features may be, I don't think they
are directed at the needs of the users of existing Access apps,
except in those cases where the Access app needs to be ported to the
web. I know that question comes up a lot, and this will be a new and
attractive alternative to the not-so-attractive set of alternatives
that have been available before.

But that's not *my* client base, so I'm having some difficulty
seeing how this is going to benefit the people who pay my bills.

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

Relevant Pages

  • Re: Getting Starting in JavaScript et al
    ... The app will be internal for the projected future. ... For the Web end, it will be JavaScript, VBScript, ASP ... It will be JavaScript on the client side and VBScript on the ... Good webapps run on any browser. ...
    (comp.lang.javascript)
  • Re: Are ASP.NET user interfaces essentially dead now?
    ... > Not sure what you mean by "IE client by definition is not user friendly". ... > The browser has nothing to do with whether a site is friendly or not. ... >> WindowsForm app (most of them don't even notice they're not under IE ... >> WindowsForms are a HELL of a lot more secure (no IE attached activex ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Steve Jobs Dismisses Java As "Heavyweight" in an Age of Lightweight Computing
    ... but do you think that the rich client market is as less as 5 ... GUI in a desktop app. ... I think the concentration on browser ...
    (comp.lang.java.programmer)
  • Re: Verizon Android Phones Flood onto craigslist
    ... The reason for using an email client is to have it check for email ... never have to use the browser to check and read email. ... But is the Yahoo mail app downloading all the mail from your Yahoo ... Seems some people need an app to tell them when it's time to wipe... ...
    (alt.cellular.verizon)
  • Re: Subscript out of range, obvious?
    ... All your client apps could declare that logging object WithEvents ... that they all get an event notification when your master app posts ... My master app is trying ... I copied this error handler from my existing code. ...
    (microsoft.public.vb.general.discussion)