From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)> wrote in

> 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
usenet at dfenton dot com
From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)> wrote in

> "David W. Fenton" <XXXusenet(a)> wrote in message
> news:Xns9CBDCEFF45EEFf99a49ed1d0c49c5bbb2(a)
>> "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)> wrote in
>> news:QBqJm.2507$rE5.2452(a)newsfe08.iad:
>>> "David W. Fenton" <XXXusenet(a)> wrote in
>>> message
>>> news:Xns9CBCC354C8849f99a49ed1d0c49c5bbb2(a)
>>>> 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

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

David W. Fenton
usenet at dfenton dot com
From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)> wrote in

> "David W. Fenton" <XXXusenet(a)> wrote in message
> news:Xns9CBDCC7B4EB9f99a49ed1d0c49c5bbb2(a)
>> 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

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
usenet at dfenton dot com
From: David W. Fenton on
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)> wrote in

> A
> 2007 list of limitations is outlined here:
> 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

DWF: Access doesn't really support decimal data type very well
(e.g., and
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

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

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

David W. Fenton
usenet at dfenton dot com
From: Salad on
David W. Fenton wrote:

> "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)> 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