Access 2010 with Sharepoint 2010
in [Help]
|
From: David W. Fenton on 9 Nov 2009 14:58 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:dyNJm.2065$cd7.1484(a)newsfe04.iad: > Watch the video again please I haven't watched the video and I'm not going to. Videos are an incredibly poor way to convey information and I haven't the time to waste on them. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 9 Nov 2009 15:10 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:dyNJm.2065$cd7.1484(a)newsfe04.iad: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > news:Xns9CBDCEFF45EEFf99a49ed1d0c49c5bbb2(a)74.209.136.93... >> "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in >> news:QBqJm.2507$rE5.2452(a)newsfe08.iad: >> >>> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in >>> message >>> news:Xns9CBCC354C8849f99a49ed1d0c49c5bbb2(a)74.209.136.91... >>> >>>> >>>> How else can you figure out what's not going to work as well in >>>> the browser as in Access itself? Surely you're not claiming >>>> that 100% of an Access app is going to convert to the >>>> browser-based Sharepoint version and have exactly the same >>>> performance and ease of use? >>> >>> Well, actually, yes I kind of am making this claim. >> >> But in other posts you're saying something completely different, >> that only the forms created in Access as web forms are converted. > > That is correct, a form designated as a web form, when published > gets converted into a web browser form (all that cool java + xml > and it is asynchronous). However that SAME form when run in the > access client runs and looks and feels just like a desktop form. > So those web forms run perfectly fine and look JUST like a regular > access forms when you run them in the access client (desktop). In > fact, just looking at those forms you can NOT tell it is a web > form. You've turned the issue upside down, Albert. I would *expect* a web form to behave like normal forms in Access. The issue that you didn't make clear is that your non-web forms are not eligible for uploading -- you have to recreate them as web forms (or is there a conversion facility?). You seem really focussed on new development, and the fact is, I'm doing virtually no new development, so I am not going to get this benefit because all the forms already exist. It's like the ADP/MDB issue (back when it still looked like MS was committed to making ADPs eventually work correctly) -- if you had an existing MDB front end connecting via ODBC to your SQL Server, it was not worth chucking it and rebuilding it as an ADP. But If you were starting new development, ADPs promised to make things a lot easier. Of course, it didn't turn out that way in the end (and I'm not suggesting that the whole Access/Sharepoint thing is going to turn out the same way, simply because these new features have no analog in pre-existing versions of Access; well, except DAPs, I guess, and we all know how well *that* turned out). My point is simply this: If you have an existing app, it's going to require a major rewrite to take advantage of web deployment (i.e., converting everything to web forms). For a new app, it might make sense to do the whole thing as web forms from the beginning. I'd sure like to see a side-by-side comparison of web and standard Access forms in terms of properties/methods/events. [] >> Can you write macros that are shared >> in multiple forms (i.e., not embedded) and those will be uploaded >> and used appropriately? Or are you limited to the embedded >> macros? > > Access has always had the above feature. You just create a macro > and it appears is the standard macro tab. So, those will upload to Sharepoint? I.e., you aren't limited to embedded macros? Of course, that brings us right back to where we started -- standard macros are hard to manage and troubleshoot. It would be great if there were a VBE-like IDE that would help you trace the interconnections between all the macros, the same way you can with VBA. This is my biggest concern about all of this, that by going to macros, you're sacrificing maintainability. >> But it's not your Access forms, but your Access *web* forms that >> you're talking about. > > Yes, but those forms created and designated as web forms make > perfectly acceptable and reasonable client forms to use and run > and develop with locally on the desktop. All irrelevant for the existing Access app, Albert, which is something you seem to have missed. [] >> But have you addressed the question about the differences between >> the free version available on Office Live, the pay version hosted >> there, and the full Sharepoint server hosted locally? Are they >> identically in functionality for a single user? > > The above issues are not set in stone yet (too early). However, > I'm making the assumption that since office live (small business) > had SharePoint services + access services free for the past two > years, then I making the assumption that the next version of > office live will also have these access services. If you've ever > launched a share point list in small business live, you'll see > that even in a web browser in table view, when you see that table, > in the upper left hand you see an access icon. It been that way > when you launch the browser in SharePoint, or office live for two+ > years that way now. This doesn't come close to answering the question. We know that the functionality is limited in comparison to standalone Sharepoint (well, others have posted about those limitations), and that full Sharepoint costs a lot of money to deploy. Surely it's not the same as the free Sharepoint in the same way that SQL Server Express is not the same as the full versions. I don't think you should be promoting Office Live as a viable platform until you know exactly what limitations that route involves. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 9 Nov 2009 15:14 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:VaOJm.29143$1g6.749(a)newsfe10.iad: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > news:Xns9CBDCC7B4EB9f99a49ed1d0c49c5bbb2(a)74.209.136.93... > >> This is a crucial problem as IIS still keeps having major >> security issues over and over again. It's simply not ready for >> prime time as an HTTP server. > > You 100% complete lost me here. IIS is a security risk. It's constantly having major vulnerabilities that other HTTP servers do not (you do understand that IIS is an HTTP server, right?)> > All of those major ISP's offer > windows IIS. A rather big portion of my clients are using windows > hosting since I require them to use ms-sql server for my software. They could use a Windows host that uses Apache and still run SQL Server. Or a Linux host running Apache that offers back-end Windows servers. This latter is the only architecture I'd contemplate, honestly, and I have no idea if anybody actually offers it or not (without it being the more expensive case where you own the box and they just colocate it next to their shared servers). > Any security issues and problems I never heard about, and it would > be really amazing that Dotster, Go Daddy and EVERY OTHER MAJOR > hosting company on the planet offers cheap affordable and > widespread use of IIS and windows hosted web sites. These > providers have BUCKETLOADS of customers using IIS and they NEVER > have any problems. They don't? I hear about problems all the time, IIS-related or not. But there are major IIS vulnerabilities coming out all the time. This is unacceptable. Apache has been much safer for many years now, as well as being faster and not limited to one OS. > Now of course since the web site is being hosted, then > any problems are that of the hosting company. If these large > hosting companies have so much security issues, then how can they > offer such cheap web hosting then? As I said, in MOST cases their > pricing is so close to the FOSS offerings as to not be an issue. > > None, not one of any customers or anyone I EVER talked to tells me > they have any difference in security issues by placing their web > site on a $7 Linux host or a $7 windows host from ISP's like > Go Daddy etc. > > They all offer both choices, and the security issues have been a\ > non issue for years for anyone I ever talked to... So you say. I'm not willing to take the risk. Windows is less secure by definition, and when the Windows web server is also less secure, you're adding too many levels of vulnerability for me to feel comfortable. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 9 Nov 2009 15:17 Albert, I think you missed one of my posts. You posted the link to the list of things that are not supported with Sharepoint for A2007, and I asked if you could take a stab at saying how that list stacks up under the forthcoming A2010. Here's the full post, and it would be great if you could address any of it that you're able: "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:AX1Jm.4744$ZF3.1279(a)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/
From: Salad on 9 Nov 2009 16:47
David W. Fenton wrote: > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:dyNJm.2065$cd7.1484(a)newsfe04.iad: > > >>Watch the video again please > > > I haven't watched the video and I'm not going to. Videos are an > incredibly poor way to convey information and I haven't the time to > waste on them. > There's an adage "A picture is worth a thousand words." that is worth considering. |