Access 2010 article
Bob Alston
From what the author says, apparently beta users are now able to
provide information on details of Access 2010. If this is true
hopefully more info will become available soon. I hope so.
Also I read that a public beta of Office 2010 is supposed to be
initially released at an event in Germany today. If so, then hopefully
the public Beta will be available pretty soon. I signed up to be
notified when it is available.
so, if beta users can now "spill their guts" about Access 2010, please
do so.
My key questions:
What limitations are there on what can be implemented on Sharepoint
services?
The author above says that there are some changes necessary to existing
apps, "an existing Access application cannot be Published to SharePoint
Server without a few changes. Indexes, relationships, lookups, primary
keys will all have to be changed".
More on the "Compatibility Wizard"
Can you create an app using modules, macros and VBA event code in form
events?
Tell me more about how the local/client side app is created, refreshed
and runs (see article above).
Where can I get my hands on Sharepoint 2010 to try it out?
Bob
Albert D. Kallal
news:YR0Jm.3575$%j4....@newsfe18.iad...
>A very interesting article.
>
>
> http://dmoffat.wordpress.com/2009/11/06/access-2010-and-sharepoint-welcome-to-the-hybrid-access-application/
>
> From what the author says, apparently beta users are now able to provide
> information on details of Access 2010. If this is true hopefully more
> info will become available soon. I hope so.
Yup...I can now blab about anything I want!!...yea!!!
I am sure you been around on some of the access sites etc and seen my access
2010 video.
If you not seen my video, here is a copy that is sitting on YouTube. You
note that in this short demo, at the 1/2 way point, I switch over to running
the application in a browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
It is VERY cool stuff...
>
> My key questions:
>
> What limitations are there on what can be implemented on Sharepoint
> services?
>
Well, the rich VBA application can sit on your desktop, but the data sits on
SharePoint. You can also have the application sit on SharePoint and a copy
gets pulled down sure local machine when you click on and on the SharePoint
site, you'll need access installed for this to occur. So, in this case we
much talking about a 100% VBA application .
> The author above says that there are some changes necessary to existing
> apps, "an existing Access application cannot be Published to SharePoint
> Server without a few changes. Indexes, relationships, lookups, primary
> keys will all have to be changed".
>
If you been using access 2007 with SharePoint, then the above issue would be
more clear. Keep in mind that when you use access with SharePoint, you're
required to use what is called a SharePoint list. This means several things,
of one of which for example is you lose some features like compound keys. A
2007 list of limitations is outlined here:
http://office.microsoft.com/en-us/access/HA101314681033.aspx?pid=CH101741461033
However with access 2010, a big portion of the above list "limitations" is
changed in a big way. The big problem(s) with access 2007 and SharePoint was
lack of referential integrity.
Access 2010 + SharePoint now supports cascade delete, and even cascade
delete restrict. What this means is basic RI is now available. Therefore if
you have a traditional master + child record relationship in access, they
can now safely make the trip up into SharePoint list and still work. We
could not do this with access 2007 and SharePoint.
In addition there's been enormous, shall I say significant improvements in
SharePoint list performance. (not to mention the fact that jet caches data
local, so in fact this setup runs very well now).
>
> Can you create an app using modules, macros and VBA event code in form
> events?
For hybrid applications, or forms that run client side, you have all the VBA
you had before. Note that you can mix both "web" forms, and VBA forms in the
same application.
However for the 100% PURE web side part? No you can't push up a VBA form to
make it run in the web browser. I think it's pretty obvious that is unlikely
were EVER going see a web server that runs and consumes VBA! It just not
going to happen! So for the web forms, you have to use macros. On the other
hand, those macros are darn cool now. Here is some screen shots and notes I
made to someone who questioned about these macros on stackoverflow:
http://stackoverflow.com/questions/1159394/data-macros-in-access2010-triggers
Remember you have some code that actually runs in the persons local browser,
and some code that runs server side. And then some code that runs for the
database engine side. This is how all database systems for the web work.
What is simply stunning is Access takes care of all of these issues. It
actually cranks out and results in an AJAX application (that is an acronym
for asynchronous java if if you're wondering).
The result is VERY cool since some things you do in an access form running
in a web browser will NOT cause a "round trip" up to the server. (code runs
local in the browser). This concept of splitting UI and data lodgic is a new
concept you'll learn when you develop these web based applications. Once you
are used are working this way, you'll never go back to the old way of doing
this. As noted in the above stack overflow article about table level data
triggers, this data lodgic feature is available for desktop only VBA
applications also.
So, for VBA, you can use the new data trigger system, however for web based
applications you find that's where most of your heavy lifting code for
manipulating data will be placed. (it don't makes sense anymore to have
recordset code trying to run in your browser that sitting on your desktop).
so these new access web forms do adopt a true web development type of model,
but access wonderfully hides all the complex parts for you.
My favorite feature about this whole web development model is that you're
using familiar access, and you don't need a database server and an server
side things set up to begin building the project. In other words your
development still occurs 100% client side, even for those web based forms.
You'll never have to play with HTML, and you'll never have to play with a
bunch of weird connection strings to some database server. In fact, it feels
like you're developing a local system.
>
> Tell me more about how the local/client side app is created, refreshed and
> runs (see article above).
The above process is really like a synchronization or send receive process
like when you're receiving email on a desktop client like outlook. What's
really cool about this is it also means that your application can run in
offline mode while you're running around, then when you find a conneciton,
then everything syncs up to your sharepoint server - this supports a
disconnected world very nicely.
For the 100% always connected Scenario, as the article points out that
distribution and synchronizing and ensuring that everyone within your
organization has the latest copy of your application becomes a snap...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com
Bob Alston
..
..
> My favorite feature about this whole web development model is that you're
> using familiar access, and you don't need a database server and an server
> side things set up to begin building the project. In other words your
> development still occurs 100% client side, even for those web based forms.
> You'll never have to play with HTML, and you'll never have to play with a
> bunch of weird connection strings to some database server. In fact, it feels
> like you're developing a local system.
>
>
..
>
>
Great Input. Keep it coming.
Are there other articles or docmentation that you can now pass along,
perhaps things that were provided to you by Microsoft?
I got the idea that the new data triggors would work both in browser
mode as well as local mode. Can you clarify a bit?
Tell me more about the VBA limitations. I tend to have bits of vba code
on many of my forms to do specific things. Are you saying that none of
that runs in a browser-enabled form?
Are there other public sources of detailed information on Access 2010
and the Access Services that you can point us to?
thanks again.
bob
Albert D. Kallal
>>
> Great Input. Keep it coming.
>
> Are there other articles or documentation that you can now pass along,
> perhaps things that were provided to you by Microsoft?
>
Hum, I have to check...I still under a NDA for things, but the embargo
on speaking about the new server features was lifted (It was lifted for
me during the SharePoint conference in las Vegas last week).
> I got the idea that the new data triggors would work both in browser mode
> as well as local mode. Can you clarify a bit?
Yes, they work for both desktop and web.
If you build a 100% desktop application that is based on VBA. Those new
table level
triggers will fire even if you open up a table using a dao reocrdset.
In fact, you can open up the accDB database file without access and use JET
(now
called ACE) and those table triggers and procedures will again run for you.
So
these data macros are true engine level triggers and code. This feature is
VERY
useful for desktop only applications.
This means we now have table level procedure code that runs at the table
level. This means we have stored procedures just like server based system
but in fact we don't have any server. I don't think there's any desktop
database system that has this procedural code type feature? (anyone???).
This also means that if you're running a standard split database on a
network with several users, the triggers + macro code will run!
Also, if you do decide to build a web based application, then again those
table level
procedures and triggers will publish (move) up to the web server
(SharePoint). They will thus then run if you use web forms to edit the data,
or client forms on the desktop that is linked to the SharePoint lists.
These data macros will thus run without you having to modify the
syntax. hence, the development process rather nice. You get to
develop local on your desktop. No need to worry about all that
server side junk. But, this stuff makes it way up to the sever
side when you publish the application.
>
> Tell me more about the VBA limitations. I tend to have bits of vba code
> on many of my forms to do specific things. Are you saying that none of
> that runs in a browser-enabled form?
correct no VBA in web forms. However, you still have forms with code and
events.
If you watch my video, you saw a few continuous forms with an edit button.
The event code behind those buttons is now going to be macro code. If you
look at that article/response of mine on stack overflow, you can see that
macros have been significantly improved.
Here is screen shot of the actual code used for on of those buttons on a
form:
http://cpedvw.bay.livefilestore.com/y1pAirBgik0Ioy7UJGFyb4GK4OvbuNDD13zWrUYgs8GJ-eRMEWVxXs79esjWeQHr7pKYj_gzsGAKLVMmjkXCCy_8sHp06jkx0ia/macro1.png
if the above link don't work, then try:
http://cid-b18a57cb5f6af0fa.skydrive.live.com/self.aspx/.Public/AccessHelp/macro1.png
With the above...click on it again to zoom..it should display correctly..
>
> Are there other public sources of detailed information on Access 2010 and
> the Access Services that you can point us to?
Best source in the last while is been the access blog here:
Some recent articles:
My room booking application:
http://blogs.msdn.com/access/archive/2009/11/03/demo-of-access-2010-room-bookings-database.aspx
Access Web Databases and The Access Show
http://blogs.msdn.com/access/archive/2009/10/19/access-web-databases-and-the-access-show.aspx
There is even more...the access blog is a great place to find out about new
stuff....
Salad
> There is even more...the access blog is a great place to find out about new
> stuff....
>
Thanks for your informative and visual comments.
What software do users require? Do all users need Access or can any
Joe Blow on the web run the app?
How does one define roles or security. For example, a guest might want
to view the rooms or the menus. You and members of the company might
want to modify the menus or promotions or ammenities in the room? You
don't want the guest to create or modify these.
Albert D. Kallal
news:KNydnYmLNfT2D2jX...@earthlink.com...
> Albert D. Kallal wrote:
>
>> There is even more...the access blog is a great place to find out about
>> new stuff....
>>
> Thanks for your informative and visual comments.
>
> What software do users require? Do all users need Access or can any Joe
> Blow on the web run the app?
>
For the web side, Joe blow can run this. This is an 100% standard
**complient** browser application. I tested that appcaion using ubuntu Linux
+ runnung FireFox and the results were perfect. There is NO activeX, and NO
silverlight downloads required of ANY kind here. Even the hightling and
shaded buttons workd 100% on the linux box.
So, Mac, Linux, Windows, SmartPhone....All you need is a stadnard complient
browser here.
> How does one define roles or security. For example, a guest might want to
> view the rooms or the menus. You and members of the company might want to
> modify the menus or promotions or ammenities in the room? You don't want
> the guest to create or modify these.
How does one do that for any web site? That is a BIG area. However, the
short answer is you have the full SharePoint security model here. That
security solves a TON of issues in terms of user Management. You can
certainly set user permissions on tables (SharePoint lists - that means
read, write, view, update etc). You can also of course filter your web
queries based on the user name. So, there is a decent number of ways to
manage these issues.
Bob Alston
OK, still more questions. If you wouldn't mind, could you please
respond to each of the questions one by one:
so you can create your access app as normal if you indeed to do a mixed
Access client / Sharepoint backend?
Once you complete your app as normal you "publish" to Sharepoint?
From then on you can use the local access app as usual, it will house
the data on sharepoint?
If another user wants to use (presumedly and is authorized at
Sharepoint) they can access Sharepoint and download or somehow get a
copy of the access front end?
Once they have the access front end, they also can use it as normal.
All their changes and your own (from the original copy of access) are
instantly updated on the sharepoint data master?
The new version of access has a new kind of form called "web forms"?
These web forms can run on your local access app just like traditional
forms do?
But these web forms can also run via a web browser alone?
Using web forms via a browser, the user needs not have a copy of MS
Access or any special software or operating system?
Are there similarly special kinds of web reports to run reports in the web?
Someone mentioned (you) that if you use this approach to access a web
only app, that AJAX is used? If correct can you elaborate?
Also I read that some data is locally cached at the user's desktop? If
correct can you provide more on this?
Lastly, does the sharepoint referential integrity provide the equivalent
that we have been used to with Access itself?
Thanks again for keeping the specifics coming. This newsgroup seems to
be the best source for details on this subject.
Bob
Biggus Dickus
wrote:
> "Bob Alston" <bobalst...@yahoo.com> wrote in message
>
> news:YR0Jm.3575$%j4....@newsfe18.iad...
>
> >A very interesting article.
>
>
> However with access 2010, a big portion of the above list "limitations" is
> changed in a big way. The big problem(s) with access 2007 and SharePoint was
> lack of referential integrity.
>
> Access 2010 + SharePoint now supports cascade delete, and even cascade
> delete restrict. What this means is basic RI is now available. Therefore if
> you have a traditional master + child record relationship in access, they
> can now safely make the trip up into SharePoint list and still work. We
> could not do this with access 2007 and SharePoint.
>
> In addition there's been enormous, shall I say significant improvements in
> SharePoint list performance. (not to mention the fact that jet caches data
> local, so in fact this setup runs very well now).
>
>
>
> > Can you create an app using modules, macros and VBA event code in form
> > events?
>
> For hybrid applications, or forms that run client side, you have all the VBA
> you had before. Note that you can mix both "web" forms, and VBA forms in the
> same application.
>
> However for the 100% PURE web side part? No you can't push up a VBA form to
> make it run in the web browser. I think it's pretty obvious that is unlikely
> were EVER going see a web server that runs and consumes VBA! It just not
> going to happen! So for the web forms, you have to use macros. On the other
> hand, those macros are darn cool now. Here is some screen shots and notes I
> made to someone who questioned about these macros on stackoverflow:
>
Great stuff Albert !! I can't believe we've never met - but I'm sure
we have some common friends (i.e. Tony T ??).
You've done a great job digging deeper on the issues here and the
questuons from Bob are sure great. I think for his atest list of
questions the answer is pretty much YES across the board (maybe a bit
simplistic :-))...
The more I work wit A2010 and SharePoint the more excited I am about
what they've done. And the more respect I have for those who
conceptualized and then delivered this product. Sure there will be
more things that people want but IMHO the number of advances in this
version are so overwhelming that anyone who bicthes about it is being
picky ...
I personally am not hugely excited about the Web-Only story here, but
there is no doubt that it will be a great addition to the toolkit of
us who develop Client-based traditional Access databases. When your
data is in SharePoint it just opens up a HUGE new world for our
clients and our data.
Best regards:
Dick Moffat
Bob Alston
Sharepoint.
do you have any demo sites you can make available?
Can you speak to specific new things you really like?
What about things you found to be different or difficult?
bob
David W. Fenton
news:AX1Jm.4744$ZF3....@newsfe13.iad:
> A
> 2007 list of limitations is outlined here:
>
> http://office.microsoft.com/en-us/access/HA101314681033.aspx?pid=CH
> 101741461033
>
> However with access 2010, a big portion of the above list
> "limitations" is changed in a big way.
Can you address that list, Albert, item by item, or at least the
ones about which you have something to say?
=====================================================================
== 1. COM object data type: SharePoint sites do not support the COM
Object data type. Result: Field is not moved.
DWF: can this be migrated to an Attachment field?
=====================================================================
== 2. Binary data type: SharePoint sites do not support the Binary
data type. Result: Field is not moved.
DWF: this seems like not much of an issue. I've never encountered
the binary data type in Access except with MakeTable queries on
columns with all Null values (Jet or Access seems to abdicate
responsibility for guessing the data type and uses Binary(512), or,
at least, it did in A2000 -- haven't checked it since then as I just
don't do MakeTables very often, but I encountered it in somebody
else's work). For binary fields used to store BLOBs, can those be
moved to attachments if they are saved out to the file system? I'd
think not, but given that I don't use this field type, there may be
lots going on that I'm not aware of.
=====================================================================
== 3. Date: SharePoint sites do not support dates prior to 1900.
Result: Data with dates prior to 1900 is not moved.
DWF: this seems a major lack to me. What's the workaround? Has it
been addressed?
=====================================================================
== 4. New line characters in text fields: SharePoint sites do not
support new line characters in a Single Line of Text field. Result:
Field is converted to a Multiple Lines of Text field or Memo field.
DWF: if you convert to the multi-value memo fields in your ACCDB, is
the order of entry of the paragraphs maintained? What happens when
you edit a paragraph in the middle after the paragraphs have been
added? Does it stay in the same location in the order of paragraphs?
If not, what is the solution? Is there any?
=====================================================================
== 5. Decimal data type: SharePoint sites do not support the Decimal
data type. Result: The Number field or Double Integer field is used
instead.
DWF: Access doesn't really support decimal data type very well
(e.g., http://allenbrowne.com/bug-08.html and
http://bytes.com/topic/access/answers/446518-decimal-data-type-jet-dd
l-sql), so I haven't used it. It would seem to be useful, but I get
by with Double, Single and Currency in my apps, all of which I
assume are supported in Sharepoint, yes?
=====================================================================
== 6. Replication ID data type: SharePoint sites do not support the
Replication ID data type. Result: A Single Line of Text data type is
used instead, depending on the type of data.
DWF: This one confuses me. What does Sharepoint use for it's PK
field? I would have assumed a GUID. In an app using GUIDs for PK, it
would seem something better ought to be done with this. Is this one
of the things addressed in supporting RI? Seems like you couldn't
very well say you support RI if you don't support the use of GUIDs
for PK/FK values.
=====================================================================
== 7. Referential integrity: SharePoint sites do not support
referential integrity. Result: Referential integrity is not enforced
in the new list.
DWF: in regard to the previous comment, are there limitations on
this besides no support for multi-column keys, as you've already
said? Any data type limitations?
=====================================================================
== 8. Default values that are not supported in a SharePoint list:
SharePoint sites accept default values that are static, such as text
or a number, as well as standard dates. Default values from Access
that are dynamic are not migrated. Result: Certain default value
properties are not moved.
DWF: is this one changed? It's not RI-related, but seems like a
pretty easy one to address, at least by adding support for the most
obvious defaults drawn from functions, such as Date() and Now().
=====================================================================
== 9. Data validation on a field or table: No data validation rules
are moved to SharePoint sites. Result: Any data validation on a
field or table is not moved or enforced.
DWF: Is this one impacted by the RI implementation? I wouldn't
expect it to be, but I could see certain table-level validation
rules fitting into an RI implementation fairly easily. This one
doesn't bother me so much, as I don't use very many of them and
could easily live without them (most of my validation is via RI or
enforced with front end controls that restrict entry; I know that's
not complete, but I find the Access validation messages that bubble
up through the UI to be annoying and too difficult to work around).
=====================================================================
== 10. Unique index fields: SharePoint sites use one unique index
field for its ID column in a list. Result: Other unique index fields
or sets of fields are not moved.
DWF: surely this one is altered by the implementation of RI, no? Of
course, if there's still no multi-column indexing, this would be
pretty problematic for a lot of cases.
=====================================================================
== 11. Relationships with cascading deletes or updates: SharePoint
sites do not support cascading deletes to related records. Result:
Deletes are not cascaded to related records, and updates are not
cascaded to related fields.
DWF: Obviously, this one is gone based on RI. Are there any notable
differences between Jet/ACE cascade other than lack of support for
cascade update (which is useless in my opinion since any field
that's going to be updated is not a proper candidate for a PK)?
=====================================================================
== 12. Relationships that enforce referential integrity: SharePoint
sites do not support referential integrity. Result: Referential
integrity is not enforced in the relationships between data in the
lists.
DWF: It's not clear to me from your comments that real RI is offered
in the new version. You've definitely said CASCADE DELETE is offered
as well as CASCADE DELETE RESTRICT (which I'd assume is the same as
enforcing RI with CASCADE DELETE set to OFF), but are column values
restricted to those drawn from the PK of a different table/list?
=====================================================================
== 13. Fields that enumerate automatically (other than the ID
field): SharePoint sites support only automatic numbering for the
field used for the ID column in a list. Result: Automatic numbering
is not applied to columns other than the ID column.
DWF: This is one that is very unclear to me. I understand that
Sharepoint in the version compatible with A2007 put all your lists
in a single table and then presented individual lists to you from
that table hiding the actual underlying implementation (or, at
least, that's my understanding), so I'd presume this means that only
one of your lists could have Sharepoint's equivalent of the Jet/ACE
Autonumber field. With a form of RI implemented, has this been
altered?
=====================================================================
== 14. Relationships in which lookups cannot be created: Some
relationships are not supported in SharePoint sites, such as when
the primary key is not related to the ID column or is not an
integer. Result: The relationship is not moved.
DWF: This one confuses me a lot. I thought *no* relationships were
moved?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
David W. Fenton
convinced, but you're doing a great job of making it very, very
tempting.
"Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
news:AX1Jm.4744$ZF3....@newsfe13.iad:
> My favorite feature about this whole web development model is that
> you're using familiar access, and you don't need a database server
> and an server side things set up to begin building the project. In
> other words your development still occurs 100% client side, even
> for those web based forms. You'll never have to play with HTML,
> and you'll never have to play with a bunch of weird connection
> strings to some database server. In fact, it feels like you're
> developing a local system.
My concern with this is that to me, it's a step backwards in terms
of maintainability. My big summer project was taking over a very old
Access app (it started life in Fall 1996 in Access 2 and has been
upgraded over the years in terms of format, but not in terms of
functionality or look and feel), and it was entirely macro-driven
(not a single line of VBA code). It also used the old-fashioned
macro-driven menus, so I had a hideous time working through the
spaghetti macros to figure out what was used where and what was
dependent on something else, and what was redundant (there was tons
of redundancy).
I like the fact that VBA code is all available in one place.
I worry about the embedded macros because it seems me that they
would lead to a lot of duplication, but if you're storing them
outside the forms/controls where they are used, then you have the
maintenance problem again.
Despite all the nice features they are adding to them (error
handling, a fabulously intuitive macro editor (or so it seems to me
from the videos I've seen), etc.), I haven't seen anything about
them that makes them more *maintainable* (I'm not worried about the
table-level macros that give you the behavior of triggers, because
those are stored exactly where they belong and shouldn't be
interacting in the same way coding does).
Because of that, it seems to me that if you're intending to put your
app up on the web, you should avoid VBA and go back to the horrors
of maintaining macro-drive apps.
Is this a real issue or not?
> The above process is really like a synchronization or send receive
> process like when you're receiving email on a desktop client like
> outlook. What's really cool about this is it also means that your
> application can run in offline mode while you're running around,
> then when you find a conneciton, then everything syncs up to your
> sharepoint server - this supports a disconnected world very
> nicely.
I'm concerned about the issue of conflicts. How do they handle that?
That is, if I disconnect and edit a few records, and when I
reconnect, it turns out that somebody else has edited the same
records while I was disconnected what happens? Same for deletes, of
course (e.g., I add child records while disconnected and before I
reconnect somebody deletes the parent record).
David W. Fenton
> For the web side, Joe blow can run this. This is an 100% standard
> **complient** browser application. I tested that appcaion using
> ubuntu Linux + runnung FireFox and the results were perfect. There
> is NO activeX, and NO silverlight downloads required of ANY kind
> here. Even the hightling and shaded buttons workd 100% on the
> linux box.
>
> So, Mac, Linux, Windows, SmartPhone....All you need is a stadnard
> complient browser here.
That is really huge, Albert.
My only concern is that for best results, you have to code your
desktop app in a certain way (well, not really code but "macro" your
app), and that's going to be a hard slog for those of us who live in
the VBA editor as our way of getting everything done efficiently and
quickly.
David W. Fenton
news:ETgJm.2403$rE5....@newsfe08.iad:
[re: security]
> the
> short answer is you have the full SharePoint security model here.
> That security solves a TON of issues in terms of user Management.
> You can certainly set user permissions on tables (SharePoint lists
> - that means read, write, view, update etc). You can also of
> course filter your web queries based on the user name. So, there
> is a decent number of ways to manage these issues.
How does this integrate with client-side security? I guess this is
ACCDB-only functionality, which means you don't have Jet ULS, but,
well, what *do* you have?
That's a real puzzler for me, actually.
It seems to me that Sharepoint adds more security/user role
management than you get with Access using ACCDB, and that bugs me a
helluva lot. It seems like a way to kill the ACE, since to architect
a real app, why not just skip ACCDB and use the Sharepoint data
store for your desktop app?
Am I missing something here?
![Tony Toews [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVFNFhAO8kxGtutFBSPYzx5Lbrrty7WRKPHNhjuWtTEHvsoQdk=s40-c)
Tony Toews [MVP]
>Thanks for all your helpful posts on this, Albert. I'm still not
>convinced, but you're doing a great job of making it very, very
>tempting.
Albert
Praise from David is well worth savouring.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
Albert D. Kallal
> It seems to me that Sharepoint adds more security/user role
> management than you get with Access using ACCDB, and that bugs me a
> helluva lot. It seems like a way to kill the ACE, since to architect
> a real app, why not just skip ACCDB and use the Sharepoint data
> store for your desktop app?
>
> Am I missing something here?
>
No, you're actually making a rather brilliant observation.
This whole thing's based on a disconnected replication model. Any user
within the organization can launch the application from the SharePoint site
and the access client will pull down a full copy of the application and
replicate all the data onto the desktop. Anyone else within the organization
who makes modifications to the application and after they sync then will
have their changes pushed up to the system. And again anybody else once
again who launches the client (which is now residing on their desktop) will
receive by that replication model any changes to the application.
In effect the whole issue of solving who has the latest copy of the data,
and who has what copy of the application is really very much eliminated. The
data is still backed up and is in an centralized location in which the I T.
department can manage. In effect this resolves the number one reason why a
lot of companies and organizations refuse to use access...
However I'm not worried about jet go away, they just did a humongous upgrade
to it and gave it all those cool table triggers and stuff. No doubt a good
bunch of the bits and pieces they changed are for all this new sharepoint
replication....but on the other hand even for longtime desktop developers we
do now have table levels triggers and procedures...
Albert D. Kallal
> Albert D. Kallal wrote:
> so you can create your access app as normal if you indeed to do a mixed
> Access client / Sharepoint backend?
>
Yes.
> Once you complete your app as normal you "publish" to Sharepoint?
>
Yes. You still have to distinguish between an client application, and that
of web based application however.
> From then on you can use the local access app as usual, it will house the
> data on sharepoint?
yes.
> If another user wants to use (presumedly and is authorized at Sharepoint)
> they can access Sharepoint and download or somehow get a copy of the
> access front end?
Yes, this process is accomplished with a link on the SharePoint site. You
click on the link and then the access client launches and sucks the
application down. It also replicates the data down, and you're now able to
work with that same application.
>
> Once they have the access front end, they also can use it as normal. All
> their changes and your own (from the original copy of access) are
> instantly updated on the sharepoint data master?
Well, ok yes, but it is more complex. The data is attempting to synchronize
itself at all times. You can even break your internet connection and keep
working. However, for things like forms and reports if you modify them, then
there's place where you see a notification that your changes have not been
set up to the server. That same notification box will also inform you that
there's pending changes that need to come down from the server. So, for
these types of changes you have to hit the sync button. Your also informed
of this changes being pending issue when you start access and an
application, and you also get information when your shutting down access.
And, you can see this info dialog in what we call backstage at all times to
inform you of this status.
>
> The new version of access has a new kind of form called "web forms"?
>
> These web forms can run on your local access app just like traditional
> forms do?
Yes, in fact you can execute "openForm" from a VBA form and the client web
form will launch.
>
> But these web forms can also run via a web browser alone?
correct
>
> Using web forms via a browser, the user needs not have a copy of MS Access
> or any special software or operating system?
Correct.
>
> Are there similarly special kinds of web reports to run reports in the
> web?
>
Reports are beyond cool (perhaps I think they're cool since I only been
looking at them last week for the first time).
I been so busy I haven't played with the web reports much. However, I was
actually doing a demo of my application to the Access VBAD group in Edmonton
last week. They cojoled me into building a report and trying it out. It was
absolutely stunning. When viewing the report on the bottom of the screen
there's a little popup icon thing you can click on and you can choose PDF,
or word (solves the local printing issues..don't it????). Anyway, I choose
the word option and went back to talking to the people. When I looked back
at the screen I stated that I don't think this option is working in beta.
Turns out that word had launched and had sucked down the report and then
rendered the report inside of a word document and it was displaying on the
screen in the SAME position (full screen) on the projector that the report
had been showing. It even had the same fonts and even the alternate line bar
shading and coloring was perfect inside of word. I hadn't realized the word
had launched! Someone in the audience had to point out to me that the report
on the screen was running/displaying in word! when I was saying it don't
work!
You can always make a printer friendly option for the report itself and
launch and print the report from a browser, but throw in this little
automatic download and local computer rendering ability to pdf or word
format, and we've have something really special on our hands here. (if
you're wondering how the system works, you don't think the axis team had the
budget to build this by themselves do you? it turns out that the whole
thing's based on SQL server web reporting services).
> Someone mentioned (you) that if you use this approach to access a web only
> app, that AJAX is used? If correct can you elaborate?
Ok, I have to be careful here, but yes. I'm not going go deep into this
area, because I'm still under NDA here, and I don't think I have permission
to speak about this.
>
> Also I read that some data is locally cached at the user's desktop? If
> correct can you provide more on this?
Well for web only stuff, of course nothing is on the client computer.
however for client based applications, yes, see my other response in this
thread..
>
> Lastly, does the sharepoint referential integrity provide the equivalent
> that we have been used to with Access itself?
Equivalent? No, it not as extensive, Cascade delete, and cascade delete
restrict are really the two big issues that we needed to be addressed and we
now have that. So, it certainly more limited than what we get with jet on
the desktop. on the other hand we do now have table triggers, and we even
have what's called validation triggers, so you could actually improve or add
your own integrity systems in this regards if you want..
There's another huge area and that's what's called the data business
connectivity services that SharePoint has. This service takes any data
source and makes it appear as a SharePoint list. So, we can consume sql
server data sources, or sap, or oracle or whatever by using this service...
Keep in mind I actually have more questions than you do at this point in
time!
Bob Alston
Any difference in the way you have to build a report to be compatible to
run web only?
Can you elaborate on the syncing, if you are web connected by using the
local client app. How much is automatic and how much must you manually
initiate a sync?
In some situations I present queries as a display, like a form or
report, to the user. Is this still possible?
ON the web only app, can I still have automatically executed code at
startup using the new macro capabilities?
Can you describe more about the new macro capability that replaces vba
for web based apps?
Thanks for the information. I am certainly excited and looking forward
to the availability of the public beta.
Bob
Albert D. Kallal
> Albert D. Kallal wrote:
>
> Any difference in the way you have to build a report to be compatible to
> run web only?
>
Yes, it somewhat different. I mean, if you select a table or web query
then which create report...you see a report.
So, the process is similar to making web forms, when you choose to create a
form, you can choose to create a client form, or a web form. The same goes
for web reports. So of course if you create a web form, then you're
automatically featured limited to what features are available in a web form
(no VBA for example). The whole process is similar in access 2007 when you
create a report in what's called layout view. So you're limited to layout
view during this whole design process.
> Can you elaborate on the syncing, if you are web connected by using the
> local client app. How much is automatic and how much must you manually
> initiate a sync?
The data is always automatic. It just design changes. Design changes to
tables go up instant (adding indexes, or adding new columns etc). However
for forms, reports, query etc, it is as I explained. The backstage dialog
looks like:
http://cid-b18a57cb5f6af0fa.skydrive.live.com/self.aspx/.Public/AccessHelp/backstage1.png
(note that after you see the above picture..you can click on it a gain to
zoom in.).
So, in the above, you can seen that my changes have not been sent up, but
there nothing waiting to come down.
> In some situations I present queries as a display, like a form or report,
> to the user. Is this still possible?
In client side, sure...but not for web side...
>
> ON the web only app, can I still have automatically executed code at
> startup using the new macro capabilities?
Well, you can simply specify the startup form just like you can now.
(in fact, you can specify the client startup form, and also specify
a different form that starts up when you run for the web
(just a additional option right under the client
form option in the same place that option is in a2007).
Not tried create an autoexec web macro, I don't think that works, but
I not tried doing that yet. However, the forms on-load event could call
your macro anyway.
>
> Can you describe more about the new macro capability that replaces vba for
> web based apps?
>
Brilliant would one word. It is capable and simple at the same time.
You will have to become more "creative" in how you do some things. At
first, you think there is too many missing features. You become
frustrated.
The development system does force you do things that in effect
makes you support a TRUE web development model. For example you not going
traverse a recordset inside of your forms code. In fact, you have to use a
data macro to traverse records (and they not quite called recordsets
anymore!).
Anyway, your forms macro code (we call them UI macros by the way) can call
that
data macro.
You don't really think about this, but what this REALLY means is your
browser code
can call data processing code that running on the database server side. They
don't
tell you that, and you really don't have to think aloud about this. You sit
down and
discover that you need to traverse some records, and you find that only data
macros let
you do this. So, you figure, ok, lets call that data macro from the UI macro
in your form.
In effect, you writing true multi-tier true MASSIVE SCALABLE web
applications without knowing it. Keep in mind this whole system is designed
with cloud services, so it will scale huge to many many users over many many
servers. You can scale out to as many users as you want. No more can anyone
ever say that access can't scale..it scales huge now...
Where I come from, this is all right out of a science fiction movie, and the
movie is called access 2010 from planet zentar...
Salad
>>
>>What software do users require? Do all users need Access or can any Joe
>>Blow on the web run the app?
>
> For the web side, Joe blow can run this. This is an 100% standard
> **complient** browser application. I tested that appcaion using ubuntu Linux
> + runnung FireFox and the results were perfect. There is NO activeX, and NO
> silverlight downloads required of ANY kind here. Even the hightling and
> shaded buttons workd 100% on the linux box.
Hi Albert. I could have started a new thread but I'm hoping you'll read
this and maybe provide an answer.
In A2007 one could do Email data collection. Ask for the recipient to
fill out the email, send it back, and Outlook would feed the reply into
into A2007. But the email form was a bit clunky and I don't think it
permitted generic trapping of data entry. Has this feature been
improved in A2010?
Albert D. Kallal
> In A2007 one could do Email data collection. Ask for the recipient to
> fill out the email, send it back, and Outlook would feed the reply into
> into A2007. But the email form was a bit clunky and I don't think it
> permitted generic trapping of data entry. Has this feature been improved
> in A2010?
I have not looked at this feature for 2010 (but, I don't think so).
I have however of recent stuck my foot in my mouth due to lack of knowledge.
For example, I was complaining about having to use send-keys + the registry
to minimize the ribbon. Now there is a command we can use to minimize the
ribbon in code and I was not aware of this.
However, no, I don't think it changed. I suppose you could build a web
system + form for this however!
David W. Fenton
> However I'm not worried about jet go away, they just did a
> humongous upgrade to it and gave it all those cool table triggers
> and stuff. No doubt a good bunch of the bits and pieces they
> changed are for all this new sharepoint replication....but on the
> other hand even for longtime desktop developers we do now have
> table levels triggers and procedures...
But this just continues what I've repeatedly stated about the ACCDB
format, that all of its innovations are related to integration with
Sharepoint. While the table-level triggers are a brilliant addition
even for those of us not likely to use Sharepoint, it's still a case
where the new features are driven by an outside need.
And the inattention to security in the ACCDB (database passwords are
not security -- they are just a joke, even with improved encryption,
because you can't build a secure app with them) suggests to me that
ACCDB becomes nothing more than Sharepoint's client-side cache for
offline work.
What happens when they start removing more features that are
important in order to integrate with Sharepoint? I had thought that
they removed ULS and Replication just because they didn't want to
support parts of Jet that have always been difficult and caused
support issues. But now, it seems obvious to me that these didn't
fit in with the Sharepoint model, so they were omitted for the
purpose of making ACCDB work more smoothly with Sharepoint.
I'm not sure which I find more disspiriting.
David W. Fenton
> The data is attempting to synchronize
> itself at all times. You can even break your internet connection
> and keep working. However, for things like forms and reports if
> you modify them, then there's place where you see a notification
> that your changes have not been set up to the server. That same
> notification box will also inform you that there's pending changes
> that need to come down from the server. So, for these types of
> changes you have to hit the sync button. Your also informed of
> this changes being pending issue when you start access and an
> application, and you also get information when your shutting down
> access. And, you can see this info dialog in what we call
> backstage at all times to inform you of this status.
Albert, you're confusing me by mixing data issues with application
issues.
In regard to an Access front-end application published to
Sharepoint, how is design and updating done? Does it put Tony out of
business?
For data I'm much more concerned, because as someone who's done a
great deal of work with Jet Replication, as well as with writing
routines to synch master/slave databases in code, I know that the
issues of conflicts are pretty central. How are data conflicts
handled, especially, delete conflicts? (I asked this is a more
detailed form in another post)
Albert D. Kallal
>
> Albert, you're confusing me by mixing data issues with application
> issues.
>
> In regard to an Access front-end application published to
> Sharepoint, how is design and updating done? Does it put Tony out of
> business?
>
Well, if you going to use SharePoint to mange the application distribution,
then you not need Tony's fantastic updater. So, SharePoint is just another
option and choice we have...
> How are data conflicts
> handled, especially, delete conflicts? (I asked this is a more
> detailed form in another post)
I don't have really have experiance here yet to offer much as to what
happends...
Tony Toews [MVP]
>This whole thing's based on a disconnected replication model. Any user
>within the organization can launch the application from the SharePoint site
>and the access client will pull down a full copy of the application and
>replicate all the data onto the desktop. Anyone else within the organization
>who makes modifications to the application and after they sync then will
>have their changes pushed up to the system. And again anybody else once
>again who launches the client (which is now residing on their desktop) will
>receive by that replication model any changes to the application.
>
>In effect the whole issue of solving who has the latest copy of the data,
>and who has what copy of the application is really very much eliminated.
Which then eliminates the need for the Auto FE Updater. Oh well. <smile>
Albert D. Kallal
news:v0bef5psbchjl562o...@4ax.com...
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote:
>
> Which then eliminates the need for the Auto FE Updater. Oh well. <smile>
>
> Tony
I don't think the vast majority of access deployments are going to be
SharePoint based anytime soon. And, I can still think of deployments
scenarios in which some linked tables reside on SharePoint, but ones does
not want or need the disconnected or replication model. In this case my bets
and recommends would still be to use your auto FE to update the front end.
Just because the access application is going to pull data from SharePoint
don't necessary mean we going to allow SharePoint to push out the
application.
We have to gain a whole new round of experience here as to how we going to
update our applications. It will take time for the dust to settle. I suspect
for mde, or accDE, the FE updater would still be a better choice even with
linked tables to SharePoint.
In fact, who knows, in the future maybe you wind up with a SharePoint
edition of your utility....
Bob Alston
sharepoint to effectively make it an MDE version - so they cannot see
nor change the forms, reports and code?
bob
Bob Alston
>
>> How are data conflicts
>> handled, especially, delete conflicts? (I asked this is a more
>> detailed form in another post)
>
> I don't have really have experiance here yet to offer much as to what
> happends...
>
>
Regarding conflicts, when working offline and then resyncing, take a
look at this:
Bob
Tony Toews [MVP]
>> Which then eliminates the need for the Auto FE Updater. Oh well. <smile>
>>
>I don't think the vast majority of access deployments are going to be
>SharePoint based anytime soon.
I would agree with that actually. I'm not overly concerned.
>In fact, who knows, in the future maybe you wind up with a SharePoint
>edition of your utility....
That's already been requested. <smile>
David W. Fenton
news:_AtJm.14408$ET3...@newsfe17.iad:
> if you create a web form, then you're
> automatically featured limited to what features are available in a
> web form (no VBA for example).
But macros? Is the event model limited to HTML form widget events,
or are they extended with AJAX?
This is pretty crucial, as it means you have a lot of choices if you
want to have the app run in the web browser and in the Access
client. It seems from what you're saying that when creating a form,
you have to choose which type. Is that correct?
How close to an HTML form are these Access web forms? That is, HTML
forms are horridly limited, ugly and lacking in basic functionality
that should have been built in when they were implemented. Surely if
you get AJAX you get more than plain vanilla HTML forms?
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CBD8425BA5Af9...@74.209.136.99...
>> How are data conflicts
>> handled, especially, delete conflicts? (I asked this is a more
>> detailed form in another post)
>
> I don't have really have experiance here yet to offer much as to
> what happends...
Huh? How could you be building a real multi-user application and not
have tested what happens when user updates conflict? This is the
most basic issue in regard to online/offline data and keeping the
two copies in synch!
I was also thinking on my bus ride into the city for a rehearsal
this afternoon that there's another issue that I wonder about:
I had previously remarked about how Sharepoint offered robust
security/roles and ACCDB does not, such that it was an alternative
as data store for apps that needed security.
But if ACCDB format is used as the offline data store, doesn't that
mean that the Sharepoint server's security is compromised by having
copies of the data on local workstations? Are these encrypted and
password protected so that non-authorized users can't get to the
data in them?
But maybe ACCDB is *not* used as your offline data store? If not,
what is? And how is security handled on that? Isn't it a major
security risk to have copies of your secure server's data lying
around on everybody's workstations?
David W. Fenton
That's only an example of the very simplest kind of conflict, an
edit to a single field in a single record by more than one user.
More complex edits, particularly those affecting RI, can be quite
hairy to resolve.
It really has the potential to be very complicated and I'm not
certain you'd want to grant unlimited permission to users to resolve
these conflicts. Who's to say the other user's edits should not win?
Are there rules on the server for resolving conflicts? E.g., can
certain users be designated to have more "authority"? Or could
offline edits be given lower priority than online edits? Can you
create custom conflict resolution scripts?
I fear that most people who haven't worked with any form of
replicated data vastly underrate the potential for difficulties
here. One of the things I've learned from all my work with Jet
Replication is that certain aspects of data schema design are
inappropriate for replicated apps. The simplest example I can think
of is the self-join. In a non-replicated app, you might have a
ParentCompanyID in your Companies table. By default, it would be
given the value of the record's own CompanyID in order to show that
it had no parent, i.e., that it was a standalone company or the top
of the hierarchy.
In a replicated app, you can't do that and enforce RI on the field
because the record can't be inserted because the ParentCompanyID
field points to a CompanyID value that doesn't exist yet until the
record is inserted.
This is the kind of subtle difference that is not obvious.
Of course, the version of Sharepoint that goes with A2010 doesn't
have that form of RI available, so it's not a valid objection there,
but my point is that there are designs and implementations that work
perfectly well in a non-replicated setup that cause problems when
your data is replicated.
Looks like if I get up to speed on Sharepoint, I might be able to
repurpose some of Jet Replication experience!
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:_AtJm.14408$ET3...@newsfe17.iad:
>
>> if you create a web form, then you're
>> automatically featured limited to what features are available in a
>> web form (no VBA for example).
>
> But macros? Is the event model limited to HTML form widget events,
> or are they extended with AJAX?
>
It all AJAX. Those macros are converted into java. The
system results in producing java and xxml. So, yes, it uses
AJAX. In fact, it based on all of the .net technologies
(presentation layer) that results in .net browser applications
(so, it based on xxml - pronounced zammel. You can Google zammel
if you want more on this presentation layer).
> This is pretty crucial, as it means you have a lot of choices if you
> want to have the app run in the web browser and in the Access
> client. It seems from what you're saying that when creating a form,
> you have to choose which type. Is that correct?
Yes, absolute, you must choose the create web form option.
> That is, HTML
> forms are horridly limited, ugly and lacking in basic functionality
Take a look at my video...the results speak for themselves..those
forms are beautiful, and more important responsive to my mouse clicks.
Albert D. Kallal
> But if ACCDB format is used as the offline data store, doesn't that
> mean that the Sharepoint server's security is compromised by having
> copies of the data on local workstations? Are these encrypted and
> password protected so that non-authorized users can't get to the
> data in them?
The above is correct You can choose to have NO local cache for
security reasons. So, during running, data can be cached in local
memory, but when you shut down the application, that data will no
reside local.
> But maybe ACCDB is *not* used as your offline data store? If not,
> what is? And how is security handled on that? Isn't it a major
> security risk to have copies of your secure server's data lying
> around on everybody's workstations?
It is a performance choice, and that of needed disconnected mode. It
is an configuring option. You can disable the local cache if you
don't want that data to stay local...
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CBDD0A3264EEf9...@74.209.136.93...
>> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
>> news:YcFJm.11310$X01....@newsfe07.iad:
>
>> But if ACCDB format is used as the offline data store, doesn't
>> that mean that the Sharepoint server's security is compromised by
>> having copies of the data on local workstations? Are these
>> encrypted and password protected so that non-authorized users
>> can't get to the data in them?
>
> The above is correct You can choose to have NO local cache for
> security reasons. So, during running, data can be cached in local
> memory, but when you shut down the application, that data will no
> reside local.
Is that the default, i.e., to not persist the offline data after you
log off?
This still sounds like a big security hole to me.
On the other hand Sharepoint is not SQL Server (even if it's using
it underneath), so if you need the kind of security that this would
be unacceptable then you have to pass up Sharepoint, I guess.
>> But maybe ACCDB is *not* used as your offline data store? If not,
>> what is? And how is security handled on that? Isn't it a major
>> security risk to have copies of your secure server's data lying
>> around on everybody's workstations?
>
> It is a performance choice, and that of needed disconnected mode.
> It is an configuring option. You can disable the local cache if
> you don't want that data to stay local...
That does sound like it's not the default. It's not clear to me that
if you disable the local cache if you can still use disconnected
mode, at least for the current session?
Salad
OK, I'll throw another topic/issue out to you. In Acess 2003 one could
do a File/Import or Link and then select Outlook, Inbox, and voila, have
the ability to view the Inbox. You could get the subject, message, even
tell if it had attachments. But it is virtually useless for associating
the message and the attachments to an Access record.
Have there been any improvements that you are aware of in helping a
developer associate an email (and attachments) with an Access record?
James A. Fortune
> A very interesting article.
>
> http://dmoffat.wordpress.com/2009/11/06/access-2010-and-sharepoint-we...
>
> From what the author says, apparently beta users are now able to
> provide information on details of Access 2010. If this is true
> hopefully more info will become available soon. I hope so.
>
> Also I read that a public beta of Office 2010 is supposed to be
> initially released at an event in Germany today. If so, then hopefully
> the public Beta will be available pretty soon. I signed up to be
> notified when it is available.
>
> so, if beta users can now "spill their guts" about Access 2010, please
> do so.
>
> My key questions:
>
> What limitations are there on what can be implemented on Sharepoint
> services?
>
> The author above says that there are some changes necessary to existing
> apps, "an existing Access application cannot be Published to SharePoint
> Server without a few changes. Indexes, relationships, lookups, primary
> keys will all have to be changed".
>
> More on the "Compatibility Wizard"
>
> Can you create an app using modules, macros and VBA event code in form
> events?
>
> Tell me more about how the local/client side app is created, refreshed
> and runs (see article above).
>
> Where can I get my hands on Sharepoint 2010 to try it out?
>
> Bob
This thread is an example of what I call it troll extol mode :-). In
spite of that, SharePoint actually has some interesting features. I
recommend that people become aware of what SharePoint has to offer to
see if those features apply to the kinds of problems they are trying
to solve. I don't ever expect to use SharePoint to develop a rich
web site, but I can safely ignore SharePoint until I need it to solve
a particular issue I have related to implementing ISO 9100 standards.
I suspect that much early SharePoint adoption was pushed on customers
by Microsoft. While a software product fulfills particular needs, it
can last, even without massive advertising. Still, I support any
attempts by any software company to improve its products and create
new products that fulfill needs. In other web areas, the rejection of
Microsoft's initiatives has been rather spectacular. Perhaps
SharePoint will turn things around for them.
James A. Fortune
CDMAP...@FortuneJames.com
Bob Alston
> This thread is an example of what I call it troll extol mode :-). In
Care to clarify why?
Bob
James A. Fortune
Let's just say that at least one poster to this thread, possibly a few
more are less than objective in their recommendations about
SharePoint. Even the troll I'm fairly certain about was effusive in
his praise of SharePoint. BTW, I just found out today that the
company I work for plans to purchase SharePoint. I was quite
surprised. The ISO 9100 issue I mentioned is that Windows Workflow
Foundation can be used to have the workflow automatically update a
company's business process documentation so that the software and the
documentation are never out of synch. I'll use VS 2008 to get up to
speed with workflows and then use SharePoint to demo the concept to
management. I'm not going to let them know I have plans for using
SharePoint (if and when it arrives) so that I will have adequate time
to learn workflows without encountering an unreasonable implementation
time schedule. If they don't get SharePoint I might just do all the
workflow programming from VS. I'm also learning how to interface .NET
with SAP in case they decide to overhaul the accounting system. My
guess is that Costing and ISO modules either don't exist or are
prohibitively expensive so they're likely to keep Access around. I'm
learning to anticipate their surprises better.
James A. Fortune
CDMAP...@FortuneJames.com
You have to design a series of football plays so that you can cash in
at the end. -- Cal (former Chicago Bear)
Tony Toews [MVP]
>> > This thread is an example of what I call it troll extol mode :-). In
>>
>> Care to clarify why?
>
>Let's just say that at least one poster to this thread, possibly a few
>more are less than objective in their recommendations about
>SharePoint. Even the troll I'm fairly certain about was effusive in
>his praise of SharePoint.
I wouldn't call Albert an extol troll. I've met Albert a number of times. Yes, he
is excited about A2010.
James A. Fortune
> "James A. Fortune" <CDMAPos...@FortuneJames.com> wrote:
>
> >> > This thread is an example of what I call it troll extol mode :-). In
>
> >> Care to clarify why?
>
> >Let's just say that at least one poster to this thread, possibly a few
> >more are less than objective in their recommendations about
> >SharePoint. Even the troll I'm fairly certain about was effusive in
> >his praise of SharePoint.
>
> I wouldn't call Albert an extol troll. I've met Albert a number of times. Yes, he
> is excited about A2010.
>
> Tony
>
I wasn't even thinking about Albert at all, except to note that MVP's
aren't totally objective almost by definition.
James A. Fortune
CDMAP...@FortuneJames.com
David W. Fenton
news:135pf5htt3vqtu91j...@4ax.com:
> "James A. Fortune" <CDMAP...@FortuneJames.com> wrote:
>
>>> > This thread is an example of what I call it troll extol mode
>>> > :-). In
>>>
>>> Care to clarify why?
>>
>>Let's just say that at least one poster to this thread, possibly a
>>few more are less than objective in their recommendations about
>>SharePoint. Even the troll I'm fairly certain about was effusive
>>in his praise of SharePoint.
>
> I wouldn't call Albert an extol troll. I've met Albert a number
> of times. Yes, he is excited about A2010.
The other thing is that Albert was not initially terribly
enthusiastic about Sharepoint. Thus, his conversion is pretty
remarkable, and thus genuinely persuasive to me.
Not that he's convinced me -- I think he's too immersed in the
Microsoft culture right now to maintain perspective on some of the
bigger issues -- but I'm certainly looking at this as something a
lot more compelling than, say, the introduction of the ADP in A2000.
Tony Toews [MVP]
>I wasn't even thinking about Albert at all, except to note that MVP's
>aren't totally objective almost by definition.
Ok. However MVPs are also MSs harshest crtiics at times. I'm watiing for Larry
Linson to jump into this thread. <smil>