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?
> 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.
> 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:
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:
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 pleaseNOOSpamKal...@msn.com
> 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?
> 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.
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?
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.
>> 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.
-- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKal...@msn.com
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.
> > 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.
> > 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:
> 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:
> 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 > pleaseNOOSpamKal...@msn.com
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.
Biggus Dickus wrote: > On Nov 6, 6:03 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com> > wrote: >> "Bob Alston" <bobalst...@yahoo.com> wrote in message
>>> 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. >> 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.
>>> 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:
>> 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:
>> 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 >> pleaseNOOSpamKal...@msn.com
> 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
So Dick, how about providing more information about Access 2010 and 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?
> 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.
===================================================================== == 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?
> 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).
> 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.
> 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?
"David W. Fenton" <XXXuse...@dfenton.com.invalid> wrote in message
> 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 (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKal...@msn.com
> 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!
-- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKal...@msn.com
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.
> 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:
(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...
-- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKal...@msn.com
Albert D. Kallal wrote: > "Salad" <o...@vinegar.com> wrote in message >>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.
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?
"Salad" <o...@vinegar.com> wrote in message > 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!
-- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKal...@msn.com
> 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.
> 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, 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...
-- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKal...@msn.com
"Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com> wrote:
>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" <PleaseNOOOsPAMmkal...@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....
-- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKal...@msn.com
|
