Re: Access 2010 with Sharepoint 2010

"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message

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.

Right, but all of the web services and soap protocol's MOSTLY use xml. So,
there is problems here, and we talking about web services here. Obviously
the cr+lf issue was addressed, but there are issues when pumping data
(tables) as xml data.

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).

Well, actually cr+lf's don't behave well in a table of data that is xml.
It often a problem for data going either way.....


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


Google xml and web services and soap....



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.

It is a great idea because it's centralizes your design and separates it
from the UI.

No question that you might want to build one query, and then from that point
on make sure that every other query you build is based on that one query.

Unfortunately that's not always practical, and that's not always the choice
developers make during the designing of their applications. If I change that
full name field, every other object in the database from many queries to
many reports to many forms will ALL benefit from this change instantly.

Furthermore what happens if some other SharePoint services needs to use that
Full Name expression?. What happens if the team down in the IT for billing
or the folks working with the sap system needs that list of customers? Again
you get to define how that field is displayed, and it stored in the data.

Now your access application on the desktop, the web server, and the IT group
of .net developers, or even the SharePoint work flow management system can
simply use that column fullname in their web services. They can all pull the
data from that table and you can be assured that the FullName column is the
same for everyone. You can't really assume that every other workflow and
Smartphone using that data will necessary be using sql to get that data
(they likely be using some web services). Storing the expression means that
everyone can use it. We really don't care what kind of technology is going
to pull out and use that data, but the data is in the table in the way that
everyone can use it.


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.

It might not be a browser that is pulling or using that data. It might be
some other web services. No matter how you slice this, you still saving
processing by doing this, you still centralizing the one place where this
expression exists and will be maintained. You don't have to care or worried
how some other system is going to pull data out. You don't know or care of
that other system has some type of expression builder. You data is just
sitting there ready to be used and consumed by any conceivable type of
application.

In addition to the above concepts, storing the value scales better. so I
suppose you could have the sharepoint services create that expression on the
fly, but that doesn't scale as well.

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.

No, but with cloud computing we are talking about 1 million small
businesses, each with only those 2 or 3 users. At the end of the day we
still scaling out to 2-3 million users here.


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?


Well, in fact that where this expression service eventually will be running.
On the other hand, this feature is great and I like having a handy dandy
expression available at the table level even if you not using sharePoint.
Again, on the desktop any other application can open up the table direct and
pull the data out. That app doesn't have to know if there's some expression
service. The data is just sitting there in the file ready to be taken.

As I said our industry is going through a really big change right now,
perhaps larger than the change from green screen to the GUI. We have to
adjust some of our development practices and programming approaches. One big
reason that is driving this is the success of cloud based vendors like
Google. We see school districts, municipalities and all kinds of
organizations going to software as a service system and using providers like
Google.

Just last week I sold a client on one of my software packages. The client is
a small startup with two users and a small office. They are istalling the
access application on their two computers, but I am hosting the data on SQL
server for them. The software sale was easy and quick and they don't even
have a file server as yet...and I don't care....

These cloud provdiers might not be as good as the desktop software, but
that's the same thing when mainframe people were saying that those desktop
computers are not reliable enough. Desktop computers were not reliable as
mainframes, but most businesses didn't care because it was cheaper and
easier.

Telling the small business that they don't have to hire that expense of
little nerd kid with funny glasses to come around and upgrade their software
on their computers is a big selling point. This is what is selling those
school districts on this stuff (no more $$ to the the evil software
companies for upgrades). Telling them that you can get rid of these expenses
is a huge selling point, so Right now in the marketplace cheap and easy is
what sells. I don't think the software systems are the best, but they're
cheap and easy. I don't think McDonald's is the best food in the land, but
it's fast and easy and available, and again that's what sells in the
marketplace.

[]

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.

Well as mentioned, see my other example in this thread, you might write a
complex payroll system with all kinds of complex code and VBA. However the
part for employees to check their holiday pay, enter their time sheets, or
perhaps choose when they are going to take time off work is ideal for
access.

The same goes for any complex access application, there still might be some
invoicing or scheduling information, or even balance owning or pricing
informaton that longtime customers would really benefit by placing that
information up on some little customer "self serve" web portal. why not let
them check this inforaton instead of phoning up a staff memeber to
accomplish and look up the information in which the customers essentially
should be able to do this themselves?

In fact pretty much most of my clients could use some type of customer serve
web portal for least some of the data in those access applicaons. In other
cases like the payroll system example, then again employees could help
themselveto some of the data that resides in those access applications, but
there is no need for, and in fact it's far better for them to not have them
have install or use the MS access applicaion...


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@xxxxxxx


.

Relevant Pages

  • Re: SOAP, WSIT, Im LOST, sort of...
    ... this mail based communication. ... the other side are different client application. ... WEB services and I can ... I guess I need some XML tool to receive and decode whetever ...
    (comp.os.vms)
  • Re: Webservice returning strings
    ... I do not know if there is an easy solution for this problem. ... see is due t the fact that Web Services return XML data. ... zips them and sends them to the client app. ...
    (microsoft.public.dotnet.languages.vb)
  • Dynamically Format XML Output?
    ... Get XML with "custom" tags. ... What I'm planning on doing is making the client provide us with an xsd ... (I just picked up web services not too long ago.) ... about importing the xsd file? ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: SOAP, WSIT, Im LOST, sort of...
    ... this mail based communication. ... the other side are different client application. ... WEB services and I can ... I guess I need some XML tool to receive and decode whetever ...
    (comp.os.vms)
  • Re: How to return a user-defined data type object from a webservice?
    ... your client ... object coming from the server via the web service is in a different ... John Saunders | MVP - Windows Server System - Connected System Developer ... It's just not how Web Services works. ...
    (microsoft.public.dotnet.framework.webservices)