Re: Access 2010 with Sharepoint 2010

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxxx> wrote in
news:5gMKm.23451$Wf2.8231@xxxxxxxxxxxx:

"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns9CC0D6FE7B925f99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxx
"Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxxx> wrote in

Now I'm really confused. Are you saying that what them mean is
that a text field cannot contain a CrLf? That's crazy.

Yes. that is the case. Given that SharePoint is darn near all xml,
so we talking the web and HTML data, then this is text data. It
much like trying to import a CSV file into ms-access, there can't
be any cr-lf's in the data stream.

Of course there can -- the file just has to be properly delimited.

I upload data with linefeeds in it to a client website all the time.
I don't use XML, just an HTML POST operation, but it works just
fine.

I do have some problems with the interaction between HTML form text
fields that somehow strip out <p> typed into them and replace them
with line feeds, but that's a different problem entirely (in the
opposite direction, in fact).

So, I just don't see what the issue is.

When it says "Field is converted to a Multiple Lines of Text
field or Memo field" does that mean it's converted to one of two
types of field, or that "Multiple Lines of Text field" is a
synonym for "Memo field"?

I'm having a hard time conceiving of a reason for making two
different kinds of text fields, one that can have CrLf in it and
one that can't -- the utility of that escapes me!

Yes, I believe the above is the case. A memo could presumably
store binary data, where the multi-line text field can't store
binary data but does allow cr+lf's. I not a real web developer
(yet!), and even passing xml data from a web service with markup
tags (for fields) does hint that no cr+lf's are allowed in the
text data stream. So, some type of data translation must/is needed
here? I believe that is the case for most web services and
explains this issue (somewhat).

I don't know anything about web services, but I've had no trouble
URL encoding data for parameters in POST operations that include
linefeeds and they go through just fine and get properly stored in
my client's MySQL database (using PHP, but the PHP doesn't touch the
data arguments for the POST parameters, it just formats the SQL
string and executes).

That's a pretty important lack, seems to me, especially given
that SQL Server has no problem with GUIDs (and it's SQL Server
that Sharepoint uses for its data store, right?).

sql is used behind the scenes but SharePoint lists are still
xml data cubes, and the whole system is designed to scale
horizontal (many many users - cloud computing, these server
farms have to scale out to millions of users).

I just Googled "xml data cube," a term that is 100% meaningless to
me, and got no useful results. Please explain.

No question that the SharePoint xml "list" has been shoe-horned
into now being a database, but that's because the success of
SharePoint and how it being used has caught everyone off guard.
The other issue is the VERY large goal of horizontal scalability
(by horizontal , not huge amounts data, but huge amounts of users)

This is yet another case (as with A2000) where MS is driving the
development of Access based on goals that are as far from the needs
of my clients as is possible. My clients don't need 100s of users.
They don't need dozens of users. They mostly don't even need more
than 2 or 3.

But Microsoft doesn't care about my clients. They haven't for a
very, very long time (despite the false dawn of Office 97 with VBA
as platform for developing complex meta-apps for small businesses).

So, you can declare a column called FullName which would be
defined as:

[FirstName] & " " & [LastName]

Note that the ACTUAL value is stored in the above column. You
don't really care that this column is an expression or is in
fact calculated and stored into the actual table because this
expression is enforced and managed at the table level by ACE.

Is it editable or just readable?

Read only. of course if you modify any field in the table that the
expression is based on, then the column data has to be updated...

I don't quite understand why this is important to implement. It
looks like something as useless to an actual Access developer as
multi-value fields.

Hmm. I have often created base queries for power users where I
did this kind of thing for them. I thinking putting it at the
table level is bad like table-level lookups, to be honest.

Yes in a pure data sense, it really breaks the relational data
rule/model of storing redundant data. On the other hand, this is
a much a scalability issue. You pull 100,000 rows, you saved that
expression being evaluated 100,000 times.

But in a browser-based app it is only run in the presentation layer.
For that matter, it is likely only calculated in Access at the
presentation layer, except when you want to sort on it.

Do these derived fields get indexed automatically, or are you
allowed to index them? That *could* be useful if you often need to
sort large amounts of data on calculated fields.

There is no question that some design decisions here are due
to this all being designed for cloud computing, and that means
processing is at a premium . So, in some cases, we going back to
"storing" aggregate totals with triggers and thus can use those
numbers without processing or having to pull more records from a
related table.

But why does this have to be put into Access? Why can't Sharepoint
do whatever it needs to scale, and leave Access alone? It's not like
you're going to have more than 255 users of an ACCDB, right?

[]

Today, we seeing a huge move towards the cloud and the web.

I don't see this for the kind of apps I have been hired to
create/revise over the last 13 years. My clients need the web, but
they don't need their database apps to be connected to it.

Both of my clients who drive public-facing websites with data that
ultimately comes from the Access apps see it as an advantage that
the data on the website is a slave of their Access app, and a subset
of it. They don't *want* 100% of the data on their websites, and
they don't want the security headaches and latency problems that
come with moving local data up to the web.

Access being married to office is good since it gets the $$, and
access being married to office also means we often get things that
are for office, and not really us access developers.

Regardless, we are receiving features that helps the product even
for non web stuff and these days I take any new bits with a smile,
especially looking at the above long list of products that were
once a common part of the desktop database market, but are now
just fond memories along with Atari and Commodore computers.

I think the web thing is a big deal. As much as I badmouth ADPs, a
lot of people got really excited about them, and I think it drove a
commitment from enterprise-level organizations that likely wouldn't
have been as strong without it. It didn't work out, unfortunately,
mostly because the reason for ADPs existing in the first place were
misguided (Jet wasn't the problem; the ignorance of developers in
understanding how to use Jet to work with ODBC data was the problem;
redesigning an Access client to bypass Jet was cutting of your nose
to spite your face, and doing it for the purpose of winning over
people who just didn't understand how they were supposed to be use
Access in the first place; but I digress...).

I fear the same tail-wags-the-dog situation with Sharepoint,
particularly given that the goals with Sharepoing are so
antithetical to the needs of the small business (at least, the small
businesses I have any interaction with).

On the other hand, if the web adaptation allows more people to do
useful things with Access, as long as they don't make it mandatory,
it's going to expand the number of people using Access, which means
it will remain a viable platform for a long time. As long as they
don't pull a Paradox4Win on us (i.e., by entirely replacing the old
development language with a new and much better one that was
completely incompatible with the old, familiar language), I think
we'll be OK. That's not the kind of thing Microsoft does, so I'm not
too worried about there being a gutting of the major features of
Access that we've become familiar with.

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

Relevant Pages