Re: Access 2010 with Sharepoint 2010

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxxx> wrote in
news:dyNJm.2065$cd7.1484@xxxxxxxxxxxx:

"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns9CBDCEFF45EEFf99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxx
"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.

That is correct, a form designated as a web form, when published
gets converted into a web browser form (all that cool java + xml
and it is asynchronous). However that SAME form when run in the
access client runs and looks and feels just like a desktop form.
So those web forms run perfectly fine and look JUST like a regular
access forms when you run them in the access client (desktop). In
fact, just looking at those forms you can NOT tell it is a web
form.

You've turned the issue upside down, Albert. I would *expect* a web
form to behave like normal forms in Access.

The issue that you didn't make clear is that your non-web forms are
not eligible for uploading -- you have to recreate them as web forms
(or is there a conversion facility?).

You seem really focussed on new development, and the fact is, I'm
doing virtually no new development, so I am not going to get this
benefit because all the forms already exist.

It's like the ADP/MDB issue (back when it still looked like MS was
committed to making ADPs eventually work correctly) -- if you had an
existing MDB front end connecting via ODBC to your SQL Server, it
was not worth chucking it and rebuilding it as an ADP. But If you
were starting new development, ADPs promised to make things a lot
easier. Of course, it didn't turn out that way in the end (and I'm
not suggesting that the whole Access/Sharepoint thing is going to
turn out the same way, simply because these new features have no
analog in pre-existing versions of Access; well, except DAPs, I
guess, and we all know how well *that* turned out).

My point is simply this:

If you have an existing app, it's going to require a major rewrite
to take advantage of web deployment (i.e., converting everything to
web forms). For a new app, it might make sense to do the whole thing
as web forms from the beginning.

I'd sure like to see a side-by-side comparison of web and standard
Access forms in terms of properties/methods/events.

[]

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?

Access has always had the above feature. You just create a macro
and it appears is the standard macro tab.

So, those will upload to Sharepoint? I.e., you aren't limited to
embedded macros?

Of course, that brings us right back to where we started -- standard
macros are hard to manage and troubleshoot. It would be great if
there were a VBE-like IDE that would help you trace the
interconnections between all the macros, the same way you can with
VBA.

This is my biggest concern about all of this, that by going to
macros, you're sacrificing maintainability.

But it's not your Access forms, but your Access *web* forms that
you're talking about.

Yes, but those forms created and designated as web forms make
perfectly acceptable and reasonable client forms to use and run
and develop with locally on the desktop.

All irrelevant for the existing Access app, Albert, which is
something you seem to have missed.

[]

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?

The above issues are not set in stone yet (too early). However,
I'm making the assumption that since office live (small business)
had SharePoint services + access services free for the past two
years, then I making the assumption that the next version of
office live will also have these access services. If you've ever
launched a share point list in small business live, you'll see
that even in a web browser in table view, when you see that table,
in the upper left hand you see an access icon. It been that way
when you launch the browser in SharePoint, or office live for two+
years that way now.

This doesn't come close to answering the question. We know that the
functionality is limited in comparison to standalone Sharepoint
(well, others have posted about those limitations), and that full
Sharepoint costs a lot of money to deploy. Surely it's not the same
as the free Sharepoint in the same way that SQL Server Express is
not the same as the full versions.

I don't think you should be promoting Office Live as a viable
platform until you know exactly what limitations that route
involves.

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

Relevant Pages

  • Re: image in webpart only is visible on local computer
    ... they wouldn't be confused over where to place image files;-) ... user's browser reads the html in the webpage and finds your ... preferable to reference the image using http://servername instead. ... Unfortunately, over the last year, SharePoint has ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: Access 2010 with Sharepoint 2010
    ... the browser as in Access itself? ... I've said elsewhere that I'm wary of embedded macros because of the ... An existing app ... that when I deploy to the client system, ...
    (comp.databases.ms-access)
  • web discussions - cant see via browser split screen
    ... I can't seem to get Web Discussions viewed via a browser ... with the Sharepoint server being the remote file server for saving. ... to finally get to the "discussion" window at the bottom of Word. ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Excel kept on asking to save file every time I jump from one sheet to another!
    ... Are any of the macros event macros? ... I am working on this Excel file that has hyperlinks and some small ... sharepoint and set the sharepoint permission to "Read Only". ... out whether there is a problem with Sharepoint or with the Excel File ...
    (microsoft.public.excel.worksheet.functions)
  • Re: Access 2010 article
    ... What limitations are there on what can be implemented on Sharepoint ... Well, the rich VBA application can sit on your desktop, but the data sits on ... Server without a few changes. ... make it run in the web browser. ...
    (comp.databases.ms-access)