Access 2010 with Sharepoint 2010
Bob Alston
Of key interest to me was these two points:
"You can run SharePoint 2010 for development on a Vista or Windows 7
client."
Hopefully this means you can test out the Access 2010 in a browser
capabilities.
"SharePoint 2010 supports all popular browsers and provides XHTML, WCAG
2.0 AA compliance. Level 1 browsers, which support 100 percent
functionality, include 32- bit versions of IE7, IE8, and Firefox on
Windows. Level 2 browsers are IE7 and IE8 x64, Safari, Firefox on other
platforms. Level 2 browsers will have some limitations in rendering and
behavior."
Bob
Albert D. Kallal
news:KdkJm.7661$de6....@newsfe21.iad...
>I found this article
>
> http://sharepointproconnections.com/Articles/tabid/149/nodeid/1996/SharePoint-Wish-List--Does-SharePoint-2010-Deliver-.aspx
>
> Of key interest to me was these two points:
>
>
> "You can run SharePoint 2010 for development on a Vista or Windows 7
> client."
>
> Hopefully this means you can test out the Access 2010 in a browser
> capabilities.
>
Well, the question is do you really need to go to all that trouble?
I mean in traditional web development, you usually have to adopt what is
called a develpment stack. that means you need to adopt a web server, a
database server, and probably choose a particular browser scripting language
on top of this. And, some type of scripting language to run on the web
server side of things is also a big help.
A pupular stack for example is lamp (Linux, Apache, mySQL, PHP).
On the other hand if you start developing in asp.net, then you'll need a
windows based web server to run "Internet services" (in place of the Apahce
web server for example).
If you're writing your software to mySQL, but that web server is
only running Microsoft's SQL server, then again you're out of luck. (you'll
either have to change hosting providers, or changer development practices
or software to run on that particular platform).
And, you useally need to adopt some type of browser scripting language, or
least some type of development system that will produce some type of
browser scripting compatible code for your web forms (java, or vbs Script
for example).
And, for that database server to hold your data you have to train yourself
in using SQL server, mySQL, oracle or whatever particular database server
you like. You have to learn the tools on how to create the tables, create
relationships, create triggers and stored procedures. And, you better be
sure that the target web hosting service will have and support that
particular database system + features. (believe it or not, in some cases
the web hosting provider will support a particular database system, but
some database features may not necessarily be supported).
So the database server thing can be quite a big investment of your time to
learn the database triggers, the database Stored procedure language. Even
the dialect of SQL from one vendor such as MySql is differnt then that of MS
sql server. So you write to one standard and stick with it.
The next thing you have to adopt is what type the web server you're going to
use. There is quite a few choices, but two common ones are Apache, and
another one is Microsoft's Internet services.
I could type on for a bit more here, but I think the above explains why in
most cases one individual developer tends not to build a web based
applications. You'll have a guy that does some work for the databae side of
things, and then you'll have a developer that codes the business part of the
application.
All I am saying is that you need a LOT of technologies to get a web site up
and running.
However another fantastic development stack right now in my humble opinion
is sharepoint 2010. The beauty of this system is that you can write to this
particular standard and you can be sure that your software will run if your
server or hosting provider is running that that version of shaerPoint.
Sharepoint becomes a new target environment for us people building office
automation applications. The standards and feature set will use for the
cloud is going to be sharepoint.
Just like now we build applications to the office standard (that might use
outlook, excel, and MS access on the desktop), in the future we build
applications that does all the similar functions, but all be mostly web
based. Therefore we must adopt some new office web standard that all our
customers can use.
The reason why markets like the iPhone are great is because developers can
write to the one standard for that phone and make GOOD money. The same goes
for the windows desktop: it's a standard you can write your software too and
sell into a marketplace. The same goes for the xBox 360. It is actually
critical to be aware of these market type places that exists for YOUR
software. Oracle also a good "market" because they again have a
ready made market that businesses has purchased into (and in which you can
consult into to make good money).
You can't just write one piece of software for one client and start to make
any kind of decent money in this industry. Your code (or application) has to
be reusable for more than one client.
So we now develop to a office standard (and VBA). Our next and software for
the cloud will be built to the sharepoint standard (at least it will for
me!). It's critical that one adopts a set of standard tools and development
process so that we can go from customer to customer without spending three
months to learning some new web platform (or database server) for EVERY
single differnt customer.
Anyway...I not really sure it worth it to bother to install and
setup all that SharePoint junk on your local computer? That is a LOT fo
work.
With access, it simplty brilliant and easy, all's you do the thing is say
you're building a web compatible application, and start developing. You
don't need all that server based garbage to start out. I suppose it might be
a thrill during the development process to see something go in a browser,
but it not really necessary requirement during the access development
process.
The other thing to keep in mind is that sharepoint 2010 only installs on a
64 bit machine. They don't support a 32 bit install. This is not
really huge deal, as most server based systems are gravitate toward 64 bit
requirements.
I suppose you could install sharePoint to a new computer, but I'm not really
sure what the advantage would be here, except for that of wanting to learn
more
about sharepoint?
Virtually every one of my clients from two men small companies up to some
fairly large ones all have a web site, but virtually none of them, I repeat
not one of them is hosting their own web server.
In fact of the several of my clients that attempted to host their own web
server found it to be expensive, lots of maintenance, and furthermore they
actually had some serious security problems in terms exposing and having
that web server sitting on the same network as the company network. So
walking into a small business and have a web server setup is a rather
daunting task, and in my experience most companies don't need to do it, and
it's not worth their time to do it.
Is it little wonder that the vast majority of most businesses today simply
purchase a little monthly hosting package and put their website into that
system? It far less hassle, it's far more secure, and in most cases it's far
less expensive.
Now to be honest, I did set up a virtual PC for with SharePoint for testing
with access 2007 about two years ago. However at that time I also started
ussing the free on-line edition of sharepoint at www.officelive.com. Since I
started using this free on-line edition of sharePoint I not booted my local
VPC copy of sharepoint in about two years. In other words using the free
online version of sharepoint was FAR easier to use and play and test with. I
never had to wait for it to boot or startup, and I could test/use/place the
SharePoint stuff any place and on any computer with an Internet connection.
I'm only explain the above, because when we start thinking of the world of
web development, we kinda have to view things in a different light.
There's tons of sharepoint hosting providers out there, and they're growing
by the day. So, to me sharepoint is just another web stack like a lamp that
you're gonna write your software to.
You then look for a provider to host that applciaon (or, you use the free
on-line edition of SharePoint). For sure those companies that believe in
investing in technology tend to have sharepoint internally these days
anyway. (and , this fact is rather wonderful, as again it simply expands my
market for my services I can offer to different customers). So, as
mentioned, sharePoint is much like Oracle, or other "ready" made markets
that are good for your bottom line.
Here's a video from the sharepoint conference last week, and can see the
quite a few companies now are using sharepoint as their general purpose
public facing a web services system:
http://www.mssharepointconference.com/pages/videoplayer.aspx?vhid=4
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com
David W. Fenton
news:BkmJm.1895$dc2....@newsfe20.iad:
> However another fantastic development stack right now in my humble
> opinion is sharepoint 2010. The beauty of this system is that you
> can write to this particular standard and you can be sure that
> your software will run if your server or hosting provider is
> running that that version of shaerPoint.
But that's a huge problem, Albert. As enthusiastic as I am about the
new things you're telling us about, I still see it as only viable
internally or over a VPN because IIS is just not viable as a web
server exposed directly to the Internet. Windows web hosts are more
expensive and less plentiful than your usual LAMP hosting providers,
and it has always been that way (had it not been, in 1999 I would
have been developing in Cold Fusion instead of starting to learn
PHP, which I still hate from the standpoint of its architecture).
It would be nice if Sharepoint server could be decoupled from
Windows and IIS and utilize any reasonable database server as its
data store.
I know that will never happen, since one of the main points of
Sharepoint is to force you to use Microsoft products.
But that's the only way it would ever get wide acceptance, seems to
me.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
David W. Fenton
news:BkmJm.1895$dc2....@newsfe20.iad:
> I not really sure it worth it to bother to install and
> setup all that SharePoint junk on your local computer? That is a
> LOT fo work.
I you don't have a Sharepoint server otherwise available to you, it
seems obvious that it would be useful. Why would it not?
David W. Fenton
"Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
news:BkmJm.1895$dc2....@newsfe20.iad:
> With access, it simplty brilliant and easy, all's you do the thing
> is say you're building a web compatible application, and start
> developing. You don't need all that server based garbage to start
> out. I suppose it might be a thrill during the development process
> to see something go in a browser, but it not really necessary
> requirement during the access development process.
I can't believe you said that. I would bet that if I Googled I could
find you recommending that someone not develop in A2000 and
distribute in A2003 -- you need to test your app on the deployed
platform, not just something that's compatible.
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?
Testing on all the target deployment platforms is not just a matter
of getting a thrill but a necessary part of any serious developer's
basic responsibilities.
David W. Fenton
news:BkmJm.1895$dc2....@newsfe20.iad:
> I also started
> ussing the free on-line edition of sharepoint at
> www.officelive.com.
But is it not the case that Office Live does not support all the
features of full Sharepoint Server? Sure, it's got user
restrictions, so would not necessarily be appropriate for deployment
but still useful for development, but you seem to be arguing that
our clients should host their apps on a public website that is not
controlled by them? This seems to me to be a very problematic
suggestion.
Remember how well a Microsoft subsidiary took care of the data of
all those T-Mobile Sidekick users...
Albert D. Kallal
news:Xns9CBCC2A93B81Df9...@74.209.136.91...
>
> But that's a huge problem, Albert. As enthusiastic as I am about the
> new things you're telling us about, I still see it as only viable
> internally or over a VPN because IIS is just not viable as a web
> server exposed directly to the Internet.
The above never been a problem for me. My original hosing was Linux based
(was some stupid cheap-o package) at about $12 a month. I needed + wanted ms
SQL server, so I switch up (same provider) to a windows web site. It was
only about $2 more.
I think every major web hosting provider offers both windows or Linux based
these days. I never seen or heard that purchasing very cheap-o windows based
web sites is expensive.
I mean basic hosting of a web site with 10 ms SQL server databases is $6.75
over here:
http://www.dotster.com/products/hosting/plans/basic
So, no, I don't buy that IIS is not viable and I found MANY super cheap and
VERY wide available and affordable hosting for windows these days.
Go Daddy starts Linux plans at $4.99 per month. For windows plans they
start...let me check...oh, golly...same price, a big huge $4.99 per month!
So, darn near everyone has this stuff, darn near everyone sells both Linux
or windows, and darn near everyone is cheap as dirt...
> Windows web hosts are more
> expensive and less plentiful than your usual LAMP hosting providers,
Well, $6.75 is cheap. In the above for dotster, if you downgrade to Linux,
it only $5.75.
Really a few dollars difference is just not an issue. As mentioned, for Go
Daddy, they seem to be charging the same per month for either system.
I can remember when the above type of systems use to be about $25 per month.
That stuff has become a super cheap-o commodity these days. I seen
SharePoint hosting for $15 a month now. So, these types of month fees are
pocket change for just about any type of business.
The cloud is coming, like it or not. It makes little if any sense for a
business to even have a server now. You can see that LA city council choose
Google as a replacement for office on the desktop. The same goes for some
School districts. They going 100% cloud and they don't care about a really
good word processor. Any half baked system that works anywhere and
everywhere without having to upgrade the software is how this whole thing is
going. Computing as a utility system like electricity is knocking on our
door step and it here to stay...
Albert D. Kallal
>
> 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.
You certainly have to deal with increased latency, but on the other hand
since there's no data transfer down the wire, you actually get some bonuses
perofrmance also.
You certanly have to choose a "web database" option for this to happen. When
you do this access will restrict your feature set to web only features -- in
fact this option even automatically restricts the macro feature set
available for you. So, for web forms you see a reduced set of form events
in the Property sheet for example. You also see a reduced set of events that
appear for controls on your forms.
At that point what you build on the desktop will go up to sharepoint exactly
as it is with all of its event code, on-dirty, on-curret code etc. All of it
should/will work the same in the browser. You have to use macro code (they
added embeeded macros in 2007 but it really was for 2010!).
No question there going to be a somewhat different of an experiance of
running in an browsser, but it those differences minor and something you'll
learn after publishing a few forms. From that point on there not really much
differnce . The fidelity and how those forms render in a browser is
absolutely stunning....nothing short of increiable..
So, yes, I am saying there is almost no reason to have the server bits
running during the development process.
I had the access 2010 technical preview for almost a month before we
actually got some server space to play with. I wrote that booking
application before I ever had touched or seen the sharepoint side.
So, I was able to develop an application to 100% on the desktops without
never having any server system anywhere. The day I received some server
space, was the day I published that application to the web. The only reason
why there was problems because it was a early beta product.
Access will tell you if that database is compatible with the web. If the web
app passes the compatibility checker (and it should if you started out
developing a web only application), then it will publish up to SharePoint).
As I said, compared to any other web development systems, you'll not be
playing with connection strings, you'll not be playing with HTML, you'll not
be playing with some database server. You'll simply be working with your
little local access system like you've always done.
Now you MUST design forms in the new layout mode. This feature came in
access 2007. In fact the new form layout view and control layout features in
access 2007 were done this way as a precursor to the web forms that were
comming in acess 2010.
> Testing on all the target deployment platforms is not just a matter
> of getting a thrill but a necessary part of any serious developer's
> basic responsibilities.
That's true. When I build an access application now, I build and develop the
system on my machine. I as a general rule can assume that when I deploy to
the client system, it will work the same.
So for web stuff, the paradigm is pretty darn similar for me. You really can
develop most if not all of your application on the desktop before you ever
attempt to publish it...
lyle fairfield
wrote:
> As I said, compared to any other web development systems, you'll not be
> playing with connection strings, you'll not be playing with HTML, you'll not
> be playing with some database server. You'll simply be working with your
> little local access system like you've always done.
In future rankings of world-wide disaster where do you think this will
fit among h1n1, islamic terrorism and stephen harper?
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CBCC2A93B81Df9...@74.209.136.91...
>> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
>> news:BkmJm.1895$dc2....@newsfe20.iad:
>
>>
>> But that's a huge problem, Albert. As enthusiastic as I am about
>> the new things you're telling us about, I still see it as only
>> viable internally or over a VPN because IIS is just not viable as
>> a web server exposed directly to the Internet.
>
> The above never been a problem for me. My original hosing was
> Linux based (was some stupid cheap-o package) at about $12 a
> month. I needed + wanted ms SQL server, so I switch up (same
> provider) to a windows web site. It was only about $2 more.
You're not addressing the real issue there, which is not
availability of windows-based web hosting or its cost, but the fact
that it's IIS that has to be used as the web server in order to do
ASP. 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.
[irrelevant discussion of availability and cost of Windows hosting
snipped]
> The cloud is coming, like it or not.
I think the cloud is a huge problem -- just look at the loss of data
that a Microsoft subsidiary caused for T-Mobile Sidekick users.
> It makes little if any sense for a
> business to even have a server now.
I think that's just a completely crazy position to take.
Can you really trust a 3rd party to back up your data?
To secure it from others?
To not mine it for their own purposes?
No, there is no form of "cloud computing" that I'll be recommending
to my clients any time soon. It's just got too many issues that are
outside the control of the client, not least of which could be
complete data loss (as in the case of Sidekick users).
> You can see that LA city council choose
> Google as a replacement for office on the desktop.
A really dumb decision, in my opinion. It's nuts to give Google so
much power. They are now coming under scrutiny from the US Justice
Dept. for possible anti-trust infractions because they control too
many things (the Google Books situation is a prime example).
I don't want to put all my eggs in one basket.
I want a diverse software ecosystem, and that's one of the other
reasons that I've chosen the LAMP stack for my web development
activities. It would have been much easier for me to go with ASP and
Windows hosting, but I felt it was better to keep diversity and
support other platforms. I have not been disappointed in that regard
-- Apache, for one, has been a far safer and more secure HTTP server
than IIS.
> The same goes for some
> School districts. They going 100% cloud and they don't care about
> a really good word processor. Any half baked system that works
> anywhere and everywhere without having to upgrade the software is
> how this whole thing is going. Computing as a utility system like
> electricity is knocking on our door step and it here to stay...
I think you're wildly overoptimistic. What I see is that something
like Google Docs is mildly useful for casual users (my roommate and
I maintain our household budget/expenses in Google Docs), but for
serious use, it just isn't sufficient.
And what happens when there's an outage in your Internet
connectivity?
I really don't think you've thought this one through.
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CBCC354C8849f9...@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.
> You certainly have to deal with increased latency, but on the
> other hand since there's no data transfer down the wire, you
> actually get some bonuses perofrmance also.
But the widgets in web browsers simply suck, even when extended with
AJAX.
And continuous forms? Hello?
> You certanly have to choose a "web database" option for this to
> happen. When you do this access will restrict your feature set to
> web only features -- in fact this option even automatically
> restricts the macro feature set available for you. So, for web
> forms you see a reduced set of form events in the Property sheet
> for example. You also see a reduced set of events that appear for
> controls on your forms.
Is there any documentation anywhere describing these limitations? It
would be very useful to know that.
> At that point what you build on the desktop will go up to
> sharepoint exactly as it is with all of its event code, on-dirty,
> on-curret code etc. All of it should/will work the same in the
> browser. You have to use macro code (they added embeeded macros in
> 2007 but it really was for 2010!).
I've said elsewhere that I'm wary of embedded macros because of the
maintenance and auditability problems that come with them. Is there
anything that addresses this? 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?
And can embedded macros call things outside themselves? And, of so,
to what degree?
> No question there going to be a somewhat different of an
> experiance of running in an browsser, but it those differences
> minor and something you'll learn after publishing a few forms.
> From that point on there not really much differnce . The fidelity
> and how those forms render in a browser is absolutely
> stunning....nothing short of increiable..
But it's not your Access forms, but your Access *web* forms that
you're talking about. That's a crucial difference. An existing app
can't just be converted without recreating its Access forms as web
forms, correct? Or is there conversion available, such as a SAVE AS
that strips out what isn't supported (and tells you what's omitted)?
> So, yes, I am saying there is almost no reason to have the server
> bits running during the development process.
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?
[]
> Access will tell you if that database is compatible with the web.
> If the web app passes the compatibility checker (and it should if
> you started out developing a web only application), then it will
> publish up to SharePoint).
How good is its rundown of the incompatiblities? Is it easy to work
from to get it into shape to be compatible for upload?
> As I said, compared to any other web development systems, you'll
> not be playing with connection strings, you'll not be playing with
> HTML, you'll not be playing with some database server. You'll
> simply be working with your little local access system like you've
> always done.
But not with native Access forms.
Not with standard VBA.
This means it may be *similar* to Access (and thus very easy for us
to learn), but it isn't Access as we've known it and used it in the
past.
[]
>> Testing on all the target deployment platforms is not just a
>> matter of getting a thrill but a necessary part of any serious
>> developer's basic responsibilities.
>
> That's true. When I build an access application now, I build and
> develop the system on my machine. I as a general rule can assume
> that when I deploy to the client system, it will work the same.
But you wouldn't build in A2003 for distribution on A2007 without
testing it in A2007 would you?
Likewise, you wouldn't build for Sharepoint without testing it on
the deployed version of Sharepoint.
> So for web stuff, the paradigm is pretty darn similar for me. You
> really can develop most if not all of your application on the
> desktop before you ever attempt to publish it...
I am skeptical about all of this. I think you're elliding a lot of
the differences between standard Access in order to laud the new
platform's ability to produce Web apps easily. That's value, true,
but it's not exactly what I or my clients are looking for. I don't
have any clients who need their app deployed to run in a web browser
-- not a single one. Why would it then suddenly be valuable to them
to be able to do so?
Sure, I can think of some marginal utility coming from that
capability, but if it requires major redevelopment (as it surely
will to convert an existing Access form to an Access web form), the
cost becomes high, and if there isn't a real need for web
deployment, the cost far exceeds the benefit.
Now, for new development, sure, it could be a different balance.
But I haven't had contract for a build-from-scratch brand-new Access
app of any degree of complexity in over 5 years -- all my work now
is maintaining the apps of my existing client base, and taking on
new clients with existing apps that need to be revised, updated and
expanding. Nobody is asking for web deployment. Some have needed
remote access, but WTS takes care of that without needing to alter
the existing app in any way.
So, exciting as all these new features may be, I don't think they
are directed at the needs of the users of existing Access apps,
except in those cases where the Access app needs to be ported to the
web. I know that question comes up a lot, and this will be a new and
attractive alternative to the not-so-attractive set of alternatives
that have been available before.
But that's not *my* client base, so I'm having some difficulty
seeing how this is going to benefit the people who pay my bills.
Bob Alston
<But I haven't had contract for a build-from-scratch brand-new Access
<app of any degree of complexity in over 5 years -- all my work now
<is maintaining the apps of my existing client base, and taking on
<new clients with existing apps that need to be revised, updated and
<expanding.
Perhaps then your Access business is dying.
<Nobody is asking for web deployment.
I hear of lots of people asking for web development. something that to
date I have done very little of. so David, perhaps they know you are
Access focused and look elsewhere for web development.
Bob
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:QBqJm.2507$rE5....@newsfe08.iad:
>
>> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>> news:Xns9CBCC354C8849f9...@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.
So, yes, the forms you build for the web look and feel like any access
client form and launch perfectly normal on the desktop inside of access.
this includes sub forms, and continuous forms that are designated as web.
those sub forms and continuous forms will make the trip into the web...
Watch that video again. All the forms you see in the CLIENT are set as web
forms. You see some SAME forms used in the client, and then you see the same
form running in the browser. For example when I launch the room
configuration system that is a continuous form, you see a row of repeating
buttons, and you see a row of repeating pictures etc (standard continues
form with repeating data). Watch the video,t hat SAME form runs in the
browser...
All, I repeat ALL of the forms you see running in that demo are marked as
web forms. Take a look at the video again. Even the main form that set as
the tools->startup form is a web form.
Ask yourself how could I develop an application before I ever published it?
Think about this for a second. I had that application up and running
perfectly normal on the desktop nearly a month before I ever published it.
As long as you restrict to web forms, then that application will run
perfectly normal on the desktop, or when you publish it, so yes I'm saying
you can develop 100% on the desktop and when you publish it you pretty much
guaranteed it's going to work the same.
Those web forms will look and feel just like a regular access forms when run
on the desktop. The whole idea here is that you can use the web form in your
desktop application. You don't need "two" forms, one for web, and one for
local. In fact you can even execute an open form from VBA and openform works
fine if you feed it a web form name. as mentioned, you can have a mix of VBA
forms, and web only forms in the same application.
When you publish the application, those web forms will make it up to the
web, and they'll run and render in the browser with very high fidelity.
You'll be hard pressed to tell the difference here. As I mentioned, that
includes the continuous forms and the sub forms, take a look at the video
again.
>
> But the widgets in web browsers simply suck, even when extended with
> AJAX.
>
> And continuous forms? Hello?
>
Watch the video again please...Take careful note of the forms in the client,
and then the same continues forms running in the browser. They are the SAME
forms. What this means is the forms you see running client side are set as
"web" forms.
> 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.
> 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.
So when I said it created a full blown application on the desktop, I did,
but the forms I choose to build where web ones. As I said, it's a rather
remarkable development paradigm because you can develop as you always done
on the desktop, you just have to use the web feature limited forms and you
good to go. However, to be clear, you have to set/create the form from the
start as a web form.
>
> 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.
Albert D. Kallal
> 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. 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.
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. 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...
David W. Fenton
><David Fentom wrote:
>
><But I haven't had contract for a build-from-scratch brand-new
>Access <app of any degree of complexity in over 5 years -- all my
>work now <is maintaining the apps of my existing client base, and
>taking on <new clients with existing apps that need to be revised,
>updated and <expanding.
>
> Perhaps then your Access business is dying.
I spend the vast majority of my billable hours on Access, just not
new applications.
I think one of the issues may be that Office 2007 has not been
widely deployed, and thus the new development that usually comes
with a paradigm-shifting new version of Access has not happened
because people aren't using that new version of Access, because they
are resisting the whole of that version of Office.
I think that Win7 and the forthcoming Office 2010 is going to change
all of that. I'm certainly bullish on Win7 whereas I was completely
against Vista.
I do fear that many of my clients will resist the ribbon. I am still
at the stage of finding it to be amateurish and distracting. It's
not persistent enough or uniform enough for me to feel comfortable
with it, but, again, I'm not using it all day long, so I'm not
really giving it a chance.
But it really is a big stumbling block for certain kinds of users,
seems to me (and I have lots of them). I mean, I have a client who
(rightly, in my opinion) is still upset by the transition from Word
97 to Word 2002/2003 -- the whole task pane thing is still giving
her fits (it gives *me* fits). I am also still annoyed at the moving
around of features (usually to incorporate them into the task pane).
Editing a style was hard enough in Word 97. Now it has twice the
number of steps to get to the editing dialog.
I haven't looked at Word 2007 to see if it's better organized with
the ribbons -- ah, yes, they've made it vastly easier (better even
than the Word 97 version), by simply adding a MODIFY button to any
place where you select a style. Once there, it's the same old
problem with having to dig down through dialog levels off the format
button, but at least it's much quicker to get there.
That's the kind of thing I can sell with training, but my users will
say "but I already know how to do it -- what am I gaining by
switching beyond the need to relearn everything?" And in most cases,
particularly apps like Word, it's a pretty hard sell.
><Nobody is asking for web deployment.
>
> I hear of lots of people asking for web development. something
> that to date I have done very little of. so David, perhaps they
> know you are Access focused and look elsewhere for web
> development.
I do web development as well, so that doesn't seem to me to be the
issue. Now, for significant web projects, I usually direct them to
someone who concentrates on web development (and act as the liaison
guiding the project, i.e., insuring that what gets done is actually
what the client asked for and needs), but that doesn't mean they
don't ask me about web development. My main role with most of my
clients is to be their one-person IT department, and that means all
the IT questions come to me. So, if they were needing web deployment
(or something that could be addressed with web deployment), I'd be
hearing about it. Of course, a lot of the needs that web deployment
is usually an answer to are addressed for *my* clients with either
Remote Desktop to user workstations or to Windows Terminal Server.
So, I think both of your responses are incorrect.
David W. Fenton
> 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
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CBDCEFF45EEFf9...@74.209.136.93...
>> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
>> news:QBqJm.2507$rE5....@newsfe08.iad:
>>
>>> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in
>>> message
>>> news:Xns9CBCC354C8849f9...@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
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CBDCC7B4EB9f9...@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
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" <PleaseNOOO...@msn.com> wrote in
news:AX1Jm.4744$ZF3....@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?
Salad
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:dyNJm.2065$cd7....@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.
Albert D. Kallal
>>
>> 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.
>
Well, they could, but many don't.
And, if you want to use asp.net and any database stuff, you will be using
IIS.
I mean, what the market share for IIS? Last time I looked it was
about 20%. So, you can't stand here and tell me that 1 in 5 web
servers being used is not a viable choice.
So, 1 in 5 web servers is not secure? That simply just NOT a reasonable
statement. That's like people trying to tell me that ms-access is not viable
choice because it can corrupt.
If you go to the fortune 1000 companies, then you'll see even a greater
percentage in terms of using IIS.
Simple:
Use of IIS is COMMON and widespread in our industry. Companies from Ferrari
(www.ferrari.com), General Mills (www.generalmills.com), Dell
(www.dell.com), Continental Airlines (http://www.continental.com), Kraft
Foods (http://www.kraftfoods.com), Kroger (www.http://www.kroger.com), the
list is a who's who's of corporate America uses IIS.
This list goes on FOREVER!
I'm not standing here trying to say that IIS is the number one web server on
the planet, it's not (it's shared between Apache, the IBM web sphere stuff,
and a few other vendors). However it is in VERY common use and it's common
used and widespread in our industry, any suggesting otherwise is simply not
fair..
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:dyNJm.2065$cd7....@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.
Well, unfortunately, in the other thread you asking me why I not addressed
other issues and part of that text..the reason is that I have only X number
of minutes to spend here. I spent time on the video, and it shows the web
stuff in action. It answers a lot of questions. I realize your time is
limited here, but so is mine. We can keep these debates real tight, or let
them wonder off into all kind of other issues, and when we do that, then
core questions will not be answered.
We used up valuable time and questions here that would have better been
answered by viewing that video. Anyway, those other pending questions you
have in the other threads are still pending and when I can around to
addressing them I will.
Each question asked means something else will not be answered...
David W. Fenton
> what the market share for IIS? Last time I looked it was
> about 20%.
The market share for Internet Explorer is huge and nobody in their
right mind uses it as anything but backup browser for those
badly-designed websites that are coded to require it.
The reason I eliminated ASP from consideration is precisely because
it's not cross-platform. The fact that it depends on an insecure web
server is just the final nail in the coffin.
The arguments you've made in favor of IIS would be laughed out of
the room in any non-Windows forum.
Albert D. Kallal
>
> =====================================================================
> 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?
Yes, the attachment field is a good workaround. Another approach is to
store the file (word, excel, whatever) simply on the SharePoint site
and provide a URL to that file. So, both attachment field works well,
and a simple path to a file. In fact, a path name to a file is in
fact how access does attachments on the web (see next question + answer).
> =====================================================================
> 2. Binary data type: SharePoint sites do not support the Binary
> data type. Result: Field is not moved.
I recommend storing the actual files on SharePoint. In my room booking
application I simply used the attachment field on access
to store the room pictures (I stored them inside of access, not as links
to external files). However, after I published the application then
SharePoint takes the attachments and produces separate files on the
SharePoint side (or the web server is fooling me, it possible that
the web server cranks out the URL's for this).
In fact, if you try to open an attachment from the web site by using
the access web form with the attachments, then the browser is actually
fed a web URL (path) to an physical file location on SharePoint, And thus
the appropriate application that resides on your computer will be launched.
This process is VERY similar when a web page has a link on it, and you
click on that link. So if you click on a web site that has a pdf, or word
file on a web site, then that is the behavior you get here.
> =====================================================================
> 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?
>
No change here. Looking at all of my applications, this limitation would not
be a problem. I mean if you're dealing with antiques or something before
1900 in
most cases you would not need a date field, but just a year column would
suffice anyway (the month and day become not that important for dates
earlier than 1900 anyway in most applications). If buy into the MS marketing
hype and assume that their claim of a 130 million share point users is
valid, then it would seem that this issue's just not really an issue these
days.
> =====================================================================
> 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?
They talking about the equivalent data type for standard text fields. For
memo fields with multiple lines they move up ok and preserver the cr + lf
characters. So, just like in SQL server, or in access, or in SharePoint
distinguish between memo fields and text fields. However, in a standard
text column in access we are allowed multi-lines. This one seems weird
since I was sure I typed in multiple lines into a address field and it
worked
on SharePoint. Anway, they not talking about memo fields, but standard
text collums.
> =====================================================================
> 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?
It uses an autonumber ID. SharePoint could perhaps use some type of GUID,
but for up-sized access tables we see the id as an autonumber ID to my
knowledge at this time.
> =====================================================================
> 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?
I not played with the above features a lot, but the way I see it working now
is that you using an autonumber ID as the PK, and in the child table you
have a number FK column. I don't see much beyond this setup.
Note that because we do have the new table trigger features, you could in
theory concatenation two fields together, shove the value into a column with
an unique index on that column. (however that's not the question or the
answer here, but I'm just pointing out there are some additional
possibilities because of our data triggers now which also will run on the
SharePoint side).
> =====================================================================
> 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().
We can set default values in the forms we create. We can also use the
table level triggers for calculated type expressions. And, we of
course can set defaults at the table level (static as per above).
And, in addition to above and there's also something new for access 2010
called "calculated fields". These are engine level, VERY similar to table
triggers.
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. This a really cool feature, and it's built this way for
several reasons, one of which is for scalability and performance. The above
doesn't help for setting a default value, but you can now create a virtual
column at the table level, and these will also make the trip up to
SharePoint. This means for every form, report, query etc, you have a nice
ready made FullName column. I think this features oriented toward more power
users and thus making it easy for them in the query designer, report
designer etc. have a "ready made" column with Full Name in it. However, from
a developer point of view it does centralize the expression into one place
in the whole application, and if you're to later on modify that to add the
persons salutation (Mr., Mrs. etc), than you'd only have one spot in the
whole applications despite many forms and many queries and many other areas
of the application using that full name column. So this feature once again
promotes that centralized table level development model I talk about in my
video.
>
> =====================================================================
> 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?
Well, actually now we have in addition to the table triggers events,
we have table procedure code, we also have something new called table
validation events. We have two events, one is called validate change, and
the other event is called validate delete.
The way these events work are VERY slick. These events can raise an error.
This is quite amazing because if you think about your code running in a
browser, the server has to give a message back to the browser that something
in the table did not validate for you. Of course on the access + desktop
only side this just generates an error you can trap. From a design point of
view the macro code one would write is going to be the same on the desktop
or web. One really don't have to think of the browser and server side of
things, but that's what this event does in effect when it raises an error.
As mentioned these new events including the validation events are at the ACE
engine level and are available in VBA desktop only applications.
> =====================================================================
> 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.
>
This is been changed. You can have an index on any column, and they can all
be unique.
> =====================================================================
> 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)?
Nothing I can add to the above, your conclusions are spot on.
>
> =====================================================================
> 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?
The above is a good question, I don't think child records can be added, but
I don't know (not tested). I seem to recal that even JET allowed the row
to be added if the FK collum was null...
>
> =====================================================================
> 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),
In the above case, when you linked or up-sized a access table to SharePoint,
even in 2007, you would see an auto number column that's generated and given
to you by SharePoint (this is just like moving up to sql server). In most
cases the aunumber ID remains the same, but just like upsizing to sql server
I think they can be changed (along with the FK's if need be).
> 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?
What this means:
In a standard access table, you can have an auto number column that's not
the PK. The short version of above is essentially saying that your
autonumber
column HAS to be the PK.
At the end of the day, this quite much means that each table you have will
have a PK column, and it very much going to be the ID autonumber column. To
be honest, that's how most of my access applications are like now anyway.
>
> =====================================================================
> 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?
I do believe that if you created a table level combo box in 2007, they
would/could make it up to SharePoint and when you use the list from
SharePoint, a pick list of values would appear for you. In fact my memory
serves correct, this works for both look up fields in a column, and even
for those cases when the lookup is using a "value list" that been created
at the table level. I've not used this feature, but I'm pretty sure that's
what they're talking about.
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CBE9B9C97513f9...@74.209.136.94...
[I've snipped out the ones I have no additional comments on]
=====================================================================
>> 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?
>
> No change here. Looking at all of my applications, this limitation
> would not be a problem. I mean if you're dealing with antiques or
> something before 1900 in
> most cases you would not need a date field, but just a year column
> would suffice anyway (the month and day become not that important
> for dates earlier than 1900 anyway in most applications).
Uh, you obviously don't work with much older data. Two of my
clients' apps and one of my own research databases would be broken
by this.
For the three apps mentioned above, the SQL Server date limitation
(i.e., no dates before 1/1/1753) would actually not be an issue, but
it certainly could be for historical databases. I mean, any
historical biographical database is going to have a problem with
that if it's storing people's birthdates.
> If buy into the MS marketing
> hype and assume that their claim of a 130 million share point
> users is valid, then it would seem that this issue's just not
> really an issue these days.
Well, given the fact that until Office Live you could only use
Sharepoint if you have a server, that would rather limit the users
of Sharepoing to organizations that have a server, and that mostly
means businesses of a certain size. About half of my clients do not
actually have a server, in fact, including the two whose databases
could not be ported to Sharepoint because of the date issue.
=====================================================================
>> 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?
>
> They talking about the equivalent data type for standard text
> fields. For memo fields with multiple lines they move up ok and
> preserver the cr + lf characters. So, just like in SQL server, or
> in access, or in SharePoint distinguish between memo fields and
> text fields. However, in a standard text column in access we are
> allowed multi-lines. This one seems weird since I was sure I typed
> in multiple lines into a address field and it worked
> on SharePoint. Anway, they not talking about memo fields, but
> standard text collums.
Now I'm really confused. Are you saying that what them mean is that
a text field cannot contain a CrLf? That's crazy.
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!
=====================================================================
>> 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?
>
> It uses an autonumber ID. SharePoint could perhaps use some type
> of GUID, but for up-sized access tables we see the id as an
> autonumber ID to my knowledge at this time.
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?).
Now, I wouldn't use a GUID in an Access app because of all the
problems and inconsistencies it causes, but there are actually
plenty of reasons why you could need it (and ReplicationID as PK in
a replicated database is not one of them, in my opinion).
=====================================================================
>> 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?
>
> I not played with the above features a lot, but the way I see it
> working now is that you using an autonumber ID as the PK, and in
> the child table you have a number FK column. I don't see much
> beyond this setup.
So, no text PK/FK columns? Hmm. That's kind of problematic, seems to
me.
> Note that because we do have the new table trigger features, you
> could in theory concatenation two fields together, shove the value
> into a column with an unique index on that column. (however that's
> not the question or the answer here, but I'm just pointing out
> there are some additional possibilities because of our data
> triggers now which also will run on the SharePoint side).
I used to do that without triggers in my Paradox days, and yes, it
was pretty awful.
I wouldn't worry too much about multi-column keys, as I don't think
there's much call for them. The scenarios where there is in general
would not be something I'd conceive of migrating into Sharepoint.
=====================================================================
>> 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().
>
> We can set default values in the forms we create. We can also use
> the table level triggers for calculated type expressions. And, we
> of course can set defaults at the table level (static as per
> above).
>
> And, in addition to above and there's also something new for
> access 2010 called "calculated fields". These are engine level,
> VERY similar to table triggers.
>
> 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?
> This a really cool feature, and it's built this way for
> several reasons, one of which is for scalability and performance.
> The above doesn't help for setting a default value, but you can
> now create a virtual column at the table level, and these will
> also make the trip up to SharePoint. This means for every form,
> report, query etc, you have a nice ready made FullName column. I
> think this features oriented toward more power users and thus
> making it easy for them in the query designer, report designer
> etc. have a "ready made" column with Full Name in it.
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.
> However, from
> a developer point of view it does centralize the expression into
> one place in the whole application, and if you're to later on
> modify that to add the persons salutation (Mr., Mrs. etc), than
> you'd only have one spot in the whole applications despite many
> forms and many queries and many other areas of the application
> using that full name column. So this feature once again promotes
> that centralized table level development model I talk about in my
> video.
Hmm. I'm not persuaded. As I said above, it's easy enough to build a
base query that does these kinds of things, and then build your
forms with that.
I see this as another of those "power user" features that's going to
be lots of fun to undo when I inherit those projects.
=====================================================================
>> 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?
>
> Well, actually now we have in addition to the table triggers
> events, we have table procedure code, we also have something new
> called table validation events. We have two events, one is called
> validate change, and the other event is called validate delete.
>
> The way these events work are VERY slick. These events can raise
> an error. This is quite amazing because if you think about your
> code running in a browser, the server has to give a message back
> to the browser that something in the table did not validate for
> you. Of course on the access + desktop only side this just
> generates an error you can trap. From a design point of view the
> macro code one would write is going to be the same on the desktop
> or web. One really don't have to think of the browser and server
> side of things, but that's what this event does in effect when it
> raises an error.
The table-level macros really do seem to be quite an innovation.
> As mentioned these new events including the validation events are
> at the ACE engine level and are available in VBA desktop only
> applications.
I wonder if these things would have been added to ACCDB if
Sharepoint integration were not such a driving force.
That thought worries me.
=====================================================================
>> 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?
>
> The above is a good question, I don't think child records can be
> added, but I don't know (not tested). I seem to recal that even
> JET allowed the row to be added if the FK collum was null...
...yes, as long as the FK column was not marked REQUIRED or have a
validation rule of NOT NULL.
Got it.
> At the end of the day, this quite much means that each table you
> have will have a PK column, and it very much going to be the ID
> autonumber column. To be honest, that's how most of my access
> applications are like now anyway.
Sure, but this kind of thing must annoy the natural-key zealots.
And I do believe that it's rather overkill for a small lookup table
with one column to have a surrogate key.
Thanks for your answers, Albert. It really looks like they are
putting a lot of really great ideas into this.
Salad
publishing an app to the web?
I watched a demo of it,
http://channel9.msdn.com/shows/Access/The-Access-Show-Episode-Two/ and
http://channel9.msdn.com/shows/Access/Microsoft-Access-2010-Demo/.
The people in the vid talked about Access Services and publishing to
Sharepoint. They basically said "It's time to publish to Sharepoint,
clicked a button or two, it went thru an update proces, and voila it was
ready to work with on the web.
Is it as simple as running a wizard, like the Database Splitter, and
away one goes or is there some setup background we should be learning
now? Do you see some difficulty in the process of getting the app from
the desktop to the web...iow, is it a simple click the button or one
needs to learn a certain technology in order to make it work? Would an
admin person be able to publish an app to the web or will it take a
braniac with years of experience to do so?
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
>
> Uh, you obviously don't work with much older data. Two of my
> clients' apps and one of my own research databases would be broken
> by this.
>
I don't know what the "supposed" 100,000,000 SharePoint users are doing in
this
case, I have to assume the use 3 columns?
>
> 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.
> 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).
>
> 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).
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)
>
> So, no text PK/FK columns? Hmm. That's kind of problematic, seems to
> me.
I not tested the above otherwise, but that's how I see this (someone
could jump in an correct on this, but I just not 100% sure on this one).
>> 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...
>
> 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. 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.
>Thanks for your answers, Albert. It really looks like they are
putting a lot of really great ideas into this.
You are welcome, and yes I think any investment into access is good.
When our industry changed from text/green screen to GUI, some products
did not make the jump.
I view myself as a person who is rattling a little tin up and down and
hoping Microsoft drops some coins into the little tin cup so we get new
features for ms-access.
I mean, VB6 is now 11 years old. There no new
versions of FoxPro. We don't see dBase, clipper, Revelation, KnowledgeMan,
Probase, R:BASE, Paradox, FMS-80, Reflex, they are all gone. Clipper never
even made
the jump to the GUI.
Today, we seeing a huge move towards the cloud and 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.
Albert D. Kallal
news:ZP-dndDg2u5P7GbX...@earthlink.com...
> Albert, what would you recommend in preparation for Access 2010 and
> publishing an app to the web?
>
Good question!
> Is it as simple as running a wizard, like the Database Splitter, and away
> one goes or is there some setup background we should be learning now?
ask yourself the following, have you ever upsized a couple of tables to SQL
server?
I mean if you're in an access application, it's only two or three mouse
clicks to push a table up to SQL server. In fact, it's extremely easy to
upsize a table to SQL server, and I often use the upsize option in place of
the export option, both of which are very easy to use to export a table up
into SQL server.
On the other hand, if you've never used SQL server, then trying to upsize
can be hard the 1st few times despite it being a few mouse clicks.
When I look at the questions people had in the private beta group, a good
number of them where kind of real basic beginner SharePoint related. For
example when you click the button in access to upsize the application, and
it asks you for Your SharePoint site name, well, did you create a Site on
SharePoint to hold the application? So, you better have created a site in
SharePoint BEFORE you publish. Now, anyone who used SharePoint will know
what a site is and how to create one. this would be the same as me telling
you that to type some text into word, you first have to create the word
document.
So, after I created a site, here is what a real url looks like:
https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/Test
Access2/default.aspx
The above is a site I just created. When access asks for the site to publish
to, then you need to use the base url, which is:
https://my-officehosted.spobeta.com/personal/$82n510-b54foi6vmlep/TestAccess2
Note how I removed the default.aspx part. So lot of people were pasting in
the above 1st URL above and wondering why clicking on the publish command
button was not working.
Now the above was plain just obvious to me two years ago, and it was obvious
to me when I was using SharePoint with access 2003. And it was I obvious to
me when I was using SharePoint with access 2007. If you never published any
tables to SharePoint, then the above little issue might cost you a whole
afternoon to resolve because something that's completely obvious to me is
not going to be obvious to a beginner has never done this before. so for me,
the first time I have to do this, it was frustrating.
However, all those little frustrating issues were spread over time for me.
So, my first suggestion is to get some experience with SharePoint. However,
you don't Need any SharePoint experience or knowledge or learning of any
kind to build a web application with the access client.
All you want to do is play with the absolute most basic features of
SharePoint such as create a site (a workspace). Now put some word documents
in it, open some word documents, throw up a couple of files. You just need
the most basic experience here. It don't take long, in a couple of hours
you'll be moving around and playing with SharePoint. It's fun and it's not
hard, but if you have to learn all of the SharePoint stuff, at the very same
time you're learning a whole bunch of new stuff in access, then instead of
it being a pleasant experience, it can become quite a frustrating experience
for you.
And if you don't have access to SharePoint, then sign up for the free office
live small business, that's what I did to learn SharePoint since I did not
have SharePoint anywhere else.
This whole thing of learning how to do this stuff is not hard at all, but
it's like anything else you just have to sit down and spend a bit of time
playing with this stuff.
> Do you see some difficulty in the process of getting the app from the
> desktop to the web...iow, is it a simple click the button or one needs to
> learn a certain technology in order to make it work?
To be absolutely honest, no you don't have to really learn anything about
the server side technology at all. You build a web compatible application
in access, and have a SharePoint site, then it really is a whack the button
and then you watch your progress bar as a thing gets pushed up into the
cloud.
In fact, the hard parts are changing your mind as to how some things that
you've taken for granted for so long actually become a bit of a mental
challenge.
Here is a perfect example:
Have you ever sat down to think how your navigation for your website's going
to work? I mean basic navigation from form to form in the access client is
something that I never gave a second thought about in like 10 years. And,
worse I was working with FoxPro and other products before access and the
form navigation was done VERY much the same way. So in effect I really never
had to sit down and think about the layout and how navigation for this web
application going to work.
So, for the web you now have to change how this navigation and how you go
from when form to the next is going to work.
It would not make sense for you to click on one form, and then for each form
a new copy of the browser is launched. How could you possibly control what
the user does next? This is not really an access problem is as much as it's
sitting down and starting to scribble on paper how you are going to navigate
through your application now. It only took me the better part of an
afternoon falling half asleep on a couch thinking how I going to setup the
navigation. I had never made out the web navigation, so the 1st time was
extra mental effort. Now that I made one Application , then the next ones
will
be easy....
So, some very simple things like navigation from form to form has to be
given some thought.
You'll also have to approach your software designs differently. What you've
done for years that made a lot of sense to do it in a rich client, will not
translate over to a browser based system. So this change in mentality is
hard sometimes because we're used to designing and building and doing things
without thinking about what we're doing, because we're so good at it and we
been doing such and such way for so many years.
For example you're not going to write code in a form that traverses a record
set, and it's not even allowed. For some people this is difficult since that
what you done for many years.
If you don't have patience to learn new ways to do things, then you're in
for rough ride. For example we for years in this newsgroup had FoxPro people
coming in and asking how come there's no record numbers in access? The
answer was well we don't use them in access! However, people coming over
from clipper or FoxPro/dBase III were using record numbers for all of their
programming career. Now they are being told they can not use them anymore!
If
you insist on using record numbers in your software designs that worked in
FoxPro, that design would not work in access. if you can make mental
changes like that, then the web thing in access will be frustrating.
The web stuff is exactly the same, you must be willing to very much changed
how you've done some things.
In other words, the wizard is only a couple most clicks to whack a and
publish the application.
It is everything else you have to "change" in how you approach things.
At the end of the day the question becomes the following:
Are you willing to spend a few afternoons learning this new system
as opposed to spending a very long time to learn another web development
system? Those other systems means you need some type of SQL server, some new
database trigger and programming language, learning a web server and likely
some type of web scripting language?
Developing applications that run a browser takes a tremendous amount of
technology, and you tend to have to learn several different server systems
to make it all happen. This explains why so often that web applications are
developed by a team of two or three people. One person knows the browser
scripting, one knows the web stuff and another builds the application or
logic part.
Access gives you a huge shortcut in this regards, and will allow a single
person to develop a system with a database, tables, cool forms and reports.
And, you can do it without that team of developers.
All of these things are easy, but you really have to be willing to change
your mind as to how you do some things.
If you look closely at my video, you see that most all the forms I've turned
off the record navigation buttons for example.
For me, all this learning stuff is a blast, and it very much what I crave
and do.
I love to learn these things..and that helps me a lot here...
> Would an admin person be able to publish an app to the web or will it take
> a braniac with years of experience to do so?
Like I said, the publishing part is really trivial...it the mind change that
some people can't do well.
When you see the long list of functions that disappear when inside of a
form's code, you simply can't believe how the heck you going to write an
application. For example, in a form's code you don't have the date functions
like DateSerial(), but I write a booking application in which I deal with
dates and times in the applicaion, and I had little trouble doing this (once
I got over the shock of not having those features, then realizing there was
a completely different approach here that really worked well!).
Salad
In my reader, the first URL broke and wordwrapped at the word Test so I
copy pasted Access2/default.aspx to it. Then I noticed your second URL
was the same w/o the "default.aspx". Both sends me to a page to logon
with name and pw. I guess I need a valid logon first. Is this what you
were demo'ing? Is this at this point you'd recommend signing up for
officelive?
> Now the above was plain just obvious to me two years ago, and it was obvious
> to me when I was using SharePoint with access 2003. And it was I obvious to
> me when I was using SharePoint with access 2007. If you never published any
> tables to SharePoint, then the above little issue might cost you a whole
> afternoon to resolve because something that's completely obvious to me is
> not going to be obvious to a beginner has never done this before. so for me,
> the first time I have to do this, it was frustrating.
>
> However, all those little frustrating issues were spread over time for me.
>
> So, my first suggestion is to get some experience with SharePoint. However,
> you don't Need any SharePoint experience or knowledge or learning of any
> kind to build a web application with the access client.
That will be of benefit for MS in the adoption of the new technology.
And for us. If the learning curve was so steep, it'd be hard to get
people to adapt. We want things to get easier, not harder.
> All you want to do is play with the absolute most basic features of
> SharePoint such as create a site (a workspace). Now put some word documents
> in it, open some word documents, throw up a couple of files. You just need
> the most basic experience here. It don't take long, in a couple of hours
> you'll be moving around and playing with SharePoint. It's fun and it's not
> hard, but if you have to learn all of the SharePoint stuff, at the very same
> time you're learning a whole bunch of new stuff in access, then instead of
> it being a pleasant experience, it can become quite a frustrating experience
> for you.
>
> And if you don't have access to SharePoint, then sign up for the free office
> live small business, that's what I did to learn SharePoint since I did not
> have SharePoint anywhere else.
>
> This whole thing of learning how to do this stuff is not hard at all, but
> it's like anything else you just have to sit down and spend a bit of time
> playing with this stuff.
Great advice.
It certainly sounds like it will be fun and a new challenge.
One couple of other question, if you have the time. Are all tables in
Sharepoint (for web/collaboration use) or can you have some tables in
Sharepoint and others local (like a personal table in the front end) and
others in a backend at the corporate site?
Do you have forms like Customer and CustomerWeb? If customer, it has
everything to work on the desktop, CustomerWeb for viewing on the web,
doesn't use DateSerial or other "missing" pieces? Or maybe two apps;
one for desktop use, the other for web? Or do you recommend a one-size
fits all approach?
>>Would an admin person be able to publish an app to the web or will it take
>>a braniac with years of experience to do so?
>
>
> Like I said, the publishing part is really trivial...it the mind change that
> some people can't do well.
>
> When you see the long list of functions that disappear when inside of a
> form's code, you simply can't believe how the heck you going to write an
> application. For example, in a form's code you don't have the date functions
> like DateSerial(), but I write a booking application in which I deal with
> dates and times in the applicaion, and I had little trouble doing this (once
> I got over the shock of not having those features, then realizing there was
> a completely different approach here that really worked well!).
>
>
Your response has me stoked! Thank you for the time you spent answering
my questions.
Roger
Roger
So if you don't have date() functions, how would you deal with
dateSerial()
Albert D. Kallal
>
> In my reader, the first URL broke and wordwrapped at the word Test so I
> copy pasted Access2/default.aspx to it.
Well I'm not asking you to attempt to log into my web site development
space!
> thenn I noticed your second URL was the same w/o the "default.aspx". Both
> sends me to a page to logon with name and pw. I guess I need a valid
> logon first.
Yes, I was just giving an example here are as to what a URL from SharePoint
that access is expecting when you publish. as I said, this is not a whole
lot different than explain to somebody is that you can type a few characters
into word, you have to create a blank document first or least be in a blank
document before you can start typing! This is just the same kind of thing...
>Is this what you were demo'ing?
Yes, that is the site were that demo resides right now. It is private at
this time.
> Is this at this point you'd recommend signing up for officelive?
Sure, office live was just a suggestion. As I said you don't need SharePoint
to start playing with the stuff in the access client side of things. This is
just like anything else and if you have a big term paper due tomorrow, then
I don't think tomorrow is the time that you should start learning to use
word and learn how to use word for the very first time! You can spend a bit
of time playing around with word, then when you're in a crunch for your term
paper the night before you won't be so frustrated with having to learn word
to get your paper done. In fact, I'm not really sure if this advice has
really anything to do with software at all, but just common sense and how
one approaches learning and doing things in one's life.
>
> One couple of other question, if you have the time. Are all tables in
> Sharepoint (for web/collaboration use) or can you have some tables in
> Sharepoint and others local (like a personal table in the front end) and
> others in a backend at the corporate site?
In your application, you can link to SharePoint tables, or you can link to
mdb/accDB data files that reside on your local desktop.
>
> Do you have forms like Customer and CustomerWeb?
You can certainly mix and match pieces of the application. So if you build a
payroll system, all the complex tax calculations and everything used on the
desktop by the controller/accountant guy would make sense in the rich
client. However, the part where the employees login to see what their
holiday pay is, and choose when they're going to take time off work etc,
well that part would make sense for the web portion (the web portal part).
So not only is it encouraged to have hybrid type applications, my bets are
that's what most applications will look like.
However as mentioned, if you look at my demo close, when I launch been the
client, those are the same web forms that I use for the web and I also use
them in the client. In other words a web form in the access client looks and
behaves really like any other access form you would build. So for continuous
form, or a form that navigate select you added a few records, you likely
would not have different forms for client and web.
> If customer, it has everything to work on the desktop, CustomerWeb for
> viewing on the web, doesn't use DateSerial or other "missing" pieces? Or
> maybe two apps; one for desktop use, the other for web? Or do you
> recommend a one-size fits all approach?
Well the best approach is to make a form that works for both client and the
web. However for some things like payroll processing etc then you need VBA.
Obviously only the controller/accountant person in your organization will
need the advance VBA part of the application. For employees to enter their
time sheets and hours, check their holiday pay, or even perhaps schedule
when they want their holidays, then the web portal part of the application
makes perfect sense. In fact it's better, since the average employee the
organization should not have to learn and use and figure out a complex
payroll system you write in access. So, users will not need to have a copy
of your application, and you really don't want them to have the payroll
application when they are only entering hours and timesheets into that
payroll system anyway...
Salad
Thanks for answering my questions. I got myself an OfficeLive account.
Seems most of the setup work is done, very straightforward. Now I
need to wait for Access 2010. Your prediction; early, mid, or late 2010?
Bob Alston
Now I need
> to wait for Access 2010. Your prediction; early, mid, or late 2010?
I have read that a public beta is going to be announced soon, perhaps
next week.
bob
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CC0D6FE7B925f9...@74.209.136.82...
>> "Albert D. Kallal" <PleaseNOOO...@msn.com> 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
news:ZP-dndDg2u5P7GbX...@earthlink.com:
> Is it as simple as running a wizard, like the Database Splitter,
> and away one goes or is there some setup background we should be
> learning now?
One thing I learned from my exchanges with Albert in the last few
days is that you can't do this with an existing app -- the app you
publish to the web has to be designed with the web versions of the
Access objects.
I don't know that Albert ever answered my question if there was a
conversion route from standard Access forms to web forms. It's not
like I asked only a couple of questions, so in the flurry of
questions it wouldn't surprise me if some of them just whizzed by
him without registering.
The point is that a properly-designed app will upload.
But that isn't your existing pre-A2010 Access app.
Albert D. Kallal
> Thanks for answering my questions. I got myself an OfficeLive account.
> Seems most of the setup work is done, very straightforward. Now I need to
> wait for Access 2010.
Actually, why wait? Note that for the free SharePoint stuff, you need office
live small
business, office live does not have the access stuff.
So, no need to wait, start reading up on SharePoint now...
If you have access 2003, or better access 2007, then start playing with the
SharePoint stuff now. That is the whole suggesting here. Simply try upsizing
some small tables from access to that SharePoint site. See how it all works.
Try the "off line mode"...and try the on-line mode for 2007. So, gain some
experience to upsize access 2007 tables to SharePoint. The wizard and steps
are very much the same for publish in 2010 as they are for up-sizing tables
in 2007. So, then when you get your hands on a2010, then all that time spent
learning how to do this in a2007 will prepare you for a2010.
Then, you be ready without having two learning curves occurring at the same
time. It will be less then 5 minutes affair of your time to start publishing
applications...
> Your prediction; early, mid, or late 2010?
I can only guess, but my guess is mid 2010 at best..
David W. Fenton
> When you see the long list of functions that disappear when inside
> of a form's code, you simply can't believe how the heck you going
> to write an application.
I assume you replace all of this stuff with macros, right?
James A. Fortune
wrote:
> "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com> wrote innews:F5OKm.4853$dc2....@newsfe20.iad:
>
> > When you see the long list of functions that disappear when inside
> > of a form's code, you simply can't believe how the heck you going
> > to write an application.
>
> I assume you replace all of this stuff with macros, right?
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
In:
http://groups.google.com/group/comp.databases.ms-access/msg/65f3941f7de8a50a
David Fenton said:
>CDMAPos...@FortuneJames.com wrote in
>news:1140552410.4...@o13g2000cwo.googlegroups.com:
>
>> Stephen Lebans wrote:
>>> James where in the world did you read that VBA is no longer
>>> available with Access 12? Do you know how ludicrous your
>>> statement is?
>
>> Whew. I'm glad it was ludicrous. I thought VBA was history.
>
>Do you realize what a dis-service you've done to this newsgroup by
>posting the things you've posted here? You've created a set of
>rumors that someone searching Google Groups may encounter, which may
>end up as misinformation that propagates far beyond this particular
>thread.
>
>If you didn't have any actual proof for any of your assertions, then
>you shouldn't have made such ridiculous statements.
>
>I'm beginning to recall now why I had killfiled your previous email
>address. I haven't yet decided if I'll be plonking this one, too.
>
In:
http://groups.google.com/group/comp.databases.ms-access/msg/d1ad8db081df7fdd
I quoted from Jeffrey Richter:
...Visual Basic .NET (which now subsumes Visual Basic Scripting
Edition, or VBScript, and Visual Basic for Applications, or VBA)...
so perhaps the idea is not as ludicrous now as it was back then. With
the benefit of hindsight, I see that the parts where I guessed
incorrectly were based on my lack of understanding about how Access
handles code internally. I also see that some of my other guesses
weren't so bad.
James A. Fortune
CDMAP...@FortuneJames.com
Albert D. Kallal
>
> 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
> conversion route from standard Access forms to web forms. It's not
> like I asked only a couple of questions, so in the flurry of
> questions it wouldn't surprise me if some of them just whizzed by
> him without registering.
>
There is not a conversion utility, the feature will not make into the final
build (budgets simply are not going to allow this for this version)...
> The point is that a properly-designed app will upload.
>
> But that isn't your existing pre-A2010 Access app.
>
Correct, I was quite clear, but again to be more clear: you have to create a
form that is designated as a web form for the publishing part to work, you
can't convert old ones.
Bob Alston
>
> There is not a conversion utility, the feature will not make into the final
> build (budgets simply are not going to allow this for this version)...
>
>
That is a real shame. Hopefully some enterprising individual will
develop a utility and make a few bucks.
bob
Albert D. Kallal
news:t10Lm.11024$dc2....@newsfe20.iad...
That's would be difficult. However, to get going, you most certainly can and
do import existing forms and tables and code modules etc.
Those forms will remain VBA, and not publish. At that point, you have an
application, and the parts that you want for the web such a bunch of reports
for staff or perahps some data gather forms usually go VERY quickly with the
wizards etc.
In a sense, for existing applications, all the hard part been done, the fun
puts are creating some reports and perhaps data gathering forms augment the
existing application.
At the end of the day, the problem/challenge here is they not just making a
form run inside of a browser (you can do that with terminal services).
This stuff is built around a scalable true multi-tier web development
system. The whole concept of UI and data logic etc. being separate means
that really a new approach was needed here. This model and design also bows
to cloud computing in a large way, so it really is a paradigm change...
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>>
>> 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....
That still doesn't tell me anything useful. Sounds like just another
buzzword.
>> 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.
That could be claimed for multi-value fields, also, or table-level
lookups.
It would be more compelling if there weren't already a way to make
that separation and maintain consistency, i.e., a stored QueryDef
with the derived field.
[]
> 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.
Then it should be defined in a layer *above* the table, where it
belongs.
And just to be clear, this *is* something that's both in Sharepoint
and in the new version of ACCDB, right? That is, it's a new column
type in Access?
[]
>> 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.
To me, the Access side of this is more compelling than the web side,
since I'd assume a complex web platform like Sharepoint would be
built with at least a 3-tiered structure, such that nobody but the
middle tier running on the server is running in direct communication
with the data store.
> 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.
That's what the middle tier is for.
Obviously, and Access app using and ACCDB back end has not middle
tier (it really doesn't have any tiers at all from the standpoint of
true client/server), but it does have the database engine at one
level and the presentation layer at another. So, I could see your
justification being applied to the Access side of things, as
multiple apps really would benefit from having it in the only
available shared component, the database itself.
But for the web, I just don't see the justification for putting it
in at that level.
> 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.
I would never recommend to my clients that they host anything
important on such a service. I don't trust any cloud provider to
secure the data or to be able to make and restore backups or to be
able to maintain service 100% of the time. So, if I were looking at
Sharepoint for a client, it would be on a local Sharepoint server. I
can't really think of any reason why any of my clients would ever
want to expose the Sharepoint-hosted apps to the public Internet.
While I could see using it to provide web interface for customers, I
would never deploy that as anything but a VPN-requiring app, simply
because I wouldn't want to have to have an SSL certificate (they are
expensive).
>> 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 above, I think the derived field feature is more
justifiable for Access than it is for Sharepoint, though the
justifications are different: for Access, it's having a single layer
that is accessed by everyone and is consistent, for Sharepoint, it's
the scalability issue (though I don't see how this would help that
much for any app not used by 100s of users, as opposed to your
example of a shared Sharepoint server hosting 1000s of apps).
> 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.
I don't understand this assertion of yours. None of the businesses
of any size that I've had any dealings with have been using
green-screen apps for a long time. A whole lot of green-screen apps
are still running the same back end, and taking output originally
intended for a dumb terminal and presenting it in a web browser, and
a lot of them are out there with terminal windows displaying the
same output as the dumb terminal. But I would argue several things:
1. in most cases, these back ends are running code that nobody wants
to re-architect.
2. for data entry processes, which are largely sequential and
repetitive, the green screen interface works extremely well. Hosting
the green screen app in a terminal window running on a multi-tasking
OS takes care of the problem of running multiple apps for multipler
purposes.
3. most of these apps don't benefit from being converted to a web
app, except for distributility. And for most such apps, that's
already been done.
But I don't see anyone but finance-related organizations using these
kinds of apps (i.e., green-screen apps running in a terminal
window). I'm pretty sure that if converting to a Web 2 interface
would provide productivity, the money would be there to make the
conversion.
> 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.
I think cloud-based computing is too new to declare a success.
Remember the history of offshore outsourcing -- many of the
companies that offshored their tech support to India brought it back
to the US, or left only a shallow first tier of support offshore,
and brought back the major part of it to the US (though quite often
in some low-cost area like Nebraska).
While software as service is going to fit certain kinds of
companies, I think it is not going to fit a large number of them.
And I also think it's going to be problematic because of latency,
even though even Google Apps has certain forms of offline editing.
With offline editing and synchronization, you're adding a new layer
of complexity to your data storage, and that's another place that
something can go wrong. You're also making the interface more
complicated for the users, since they have to understand the edit
conflict dialogs and act on them appropriately. I've always tried to
design my Access apps so that the users never produced any write
conflicts so they didn't have to confront the dialog asking them
what to do (whether the default one or custom ones). Cloud computing
by definition requires offline editing or it's useless (since you're
dead in the water if the Internet is down), and that means certain
additional levels of complexity for synchronizing data and for the
end users.
I just don't see the benefit.
But then, I've been heavily committed to Windows Terminal Server and
remote desktop access for a very, very long time, so perhaps my
clients have been getting the majority of the benefits from the
standpoint of access without using this particular buzzword
technology.
[rest snipped, because I've basically already addressed all the main
points in what I've written above]
David W. Fenton
> Those forms will remain VBA, and not publish. At that point, you
> have an application, and the parts that you want for the web such
> a bunch of reports for staff or perahps some data gather forms
> usually go VERY quickly with the wizards etc.
I'm not clear on whether or not forms are different from reports. To
reports have to be created as web reports as well? Obviously, a
report with VBA or that uses events not supported by the web event
model wouldn't work, but it's not clear to me from what you said
that you have to branch both of them (or replace the Access
form/report with the web version).
Have you cited any comparison of the events/properties/features that
differ between the web and Access forms?
Also, you stated in one post about struggling with getting along
without having VBA functions like Date() and the like. Is it not the
case that macros fully replace that kind of basic functionality (if
not replacing everything you can do in VBA)?
David W. Fenton
news:34adb3fe-48c9-43ae...@g27g2000yqn.googlegroups.co
m:
> On Nov 12, 4:11 pm, "David W. Fenton"
> <XXXuse...@dfenton.com.invalid> wrote:
>> "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com> wrote
>> innews:F5OKm.4853$dc2....@newsfe20.iad:
>>
>> > When you see the long list of functions that disappear when
>> > inside of a form's code, you simply can't believe how the heck
>> > you going to write an application.
>>
>> I assume you replace all of this stuff with macros, right?
>
> In:
>
> http://groups.google.com/group/comp.databases.ms-access/msg/65f3941
> f7de8a50a
But VBA is not being replaced. You won't have to use macros except
if you're building Sharepoint apps.
No doubt, many, many people won't understand that obvious
distinction and will read this as "VBA is dead." But that's only
because they have less than half the brains God promised a ham
sandwich.
> With
> the benefit of hindsight, I see that the parts where I guessed
> incorrectly were based on my lack of understanding about how
> Access handles code internally. I also see that some of my other
> guesses weren't so bad.
Nothing you said was correct.
VBA is not being replaced.
Macros are being improved to do more things and do them much better
than they used to.
I have no doubt that one day VBA *will* be replaced, but it will
likely be done in the same way that Access Basic was replaced, in a
manner that converts very easily and is very similar to the old way
(something based on VB.NET is the obvious path, though that's a much
bigger difference than between Access Basic and VBA).
Your claim is like the person who says it's going to rain on
Wednesday, and when it doesn't and then rains on Thursday says "See!
I was right, I just got some of the details wrong!"
James A. Fortune
wrote:
> "James A. Fortune" <CDMAPos...@FortuneJames.com> wrote innews:34adb3fe-48c9-43ae...@g27g2000yqn.googlegroups.co
At least I saw the storm coming :-).
I think the quote from Jeffrey Richter makes it clear that if
Microsoft could have gotten away with eliminating VBA for Access 2007,
they would have. Right then -- not at some point in the future. I
think the existence of such a plan was likely and that it got
temporarily abandoned. I have no doubt that Microsoft would love us
to move to .NET. What I saw at the time was that the direction
Microsoft was headed was at odds with the existence of VBA. Like a
politician, they decided to spread out the implementation time to make
it more gradual. VBA may not be dead, but its heyday is over. My
guesses were not as far-fetched as you imagined. I think your faith
in VBA wasn't much better than my guesses.
James A. Fortune
CDMAP...@FortuneJames.com
Salad
> "Salad" <o...@vinegar.com> wrote in message
>
>
>>Thanks for answering my questions. I got myself an OfficeLive account.
>>Seems most of the setup work is done, very straightforward. Now I need to
>>wait for Access 2010.
>
>
> Actually, why wait? Note that for the free SharePoint stuff, you need office
> live small
> business, office live does not have the access stuff.
>
> So, no need to wait, start reading up on SharePoint now...
>
> If you have access 2003, or better access 2007, then start playing with the
> SharePoint stuff now. That is the whole suggesting here. Simply try upsizing
> some small tables from access to that SharePoint site. See how it all works.
> Try the "off line mode"...and try the on-line mode for 2007. So, gain some
> experience to upsize access 2007 tables to SharePoint. The wizard and steps
> are very much the same for publish in 2010 as they are for up-sizing tables
> in 2007. So, then when you get your hands on a2010, then all that time spent
> learning how to do this in a2007 will prepare you for a2010.
>
> Then, you be ready without having two learning curves occurring at the same
> time. It will be less then 5 minutes affair of your time to start publishing
> applications...
>
>
Hi Albert. A2003. I logged into OfficeLive, got into my workspace
Workbook1 to get the URL, then I opened a database with table Junk and
attempted to export to it to my OfficeLive workspace. I got an error
"The site you specified does not support importing data from a Microsoft
Access database. The site must be running Windows Sharepoint from
Microsoft." I suppose I am doing something wrong. Any hints or ideas?
Also, in Access I might have a hyperlink to a document...something like
"Press Me!#C:\Testdoc.doc". Can one store hyperlinks to Sharepoint docs
like that? If so, how does one "extract" or know the url to save the
doc to or where the docs are located?
Is a Sharepoint link determined using the .Connect property?
Albert D. Kallal
> Hi Albert. A2003. I logged into OfficeLive
You need to use office live small business, office live does not have
ms-access support.
Here is a discussion and screen shots:
> Also, in Access I might have a hyperlink to a document...something like
> "Press Me!#C:\Testdoc.doc". Can one store hyperlinks to Sharepoint docs
> like that?
I as a rule I avoided hyperlink fields. However, yes, for SharePoint docs,
yes, you can store the docs on the server and use a web URL.
Even better is that for access 2010, any attachments you store (internal to
access) when up-sized to SharePoint actually results in a separate URL for
each attachment. Thus clicking on that attachment is like clicking on a pdf,
or word doc on a web site.
> If so, how does one "extract" or know the url to save the doc to or where
> the docs are located?
Well, if you place the document on SharePoint, then you see the URL, or can
right-click and copy the shortcut like you can for any document with a link
to it on a web site...it not any different...
David W. Fenton
:
> <XXXuse...@dfenton.com.invalid> wrote:
>> "James A. Fortune" <CDMAPos...@FortuneJames.com> wrote
>> innews:34adb3fe-48c9-43ae...@g27g2000yqn.googlegrou
>> ps.co m:
>> > In:
>>
>> >http://groups.google.com/group/comp.databases.ms-access/msg/d1ad8
>> >db
The quote is from a book that was published in 2002. This predates
MS's move to remove VBA from Excel for Mac. You *do* not what the
upshot of *that* was, don't you?
You're using an old quote from a period when things in regard to
.NET were much more theoretical than they are now, and that quote
seems to me to be one of *wishing* something rather than stating a
fact.
> Right then -- not at some point in the future. I
> think the existence of such a plan was likely and that it got
> temporarily abandoned.
I think you've really got the time frame out of whack. A book with a
publication date of 2002 was published in 2001. Thus, its content
predates not just A2007, but A2002 and A2003. Certainly 2002 and
2003 were surely largely in the can already or feature-complete in
terms of planning, but the differences between 2003 and 2007 are not
in regard to VBA integration, so there's absolutely no evidence of
abandonment of VBA.
Of course, you could see embedded macros as evidence of that, but I
would say that those are there as part of the integration with
Sharepoint, which seems much more important to Microsoft than
killing VBA in Access. You might see the whole Sharepoint thing as a
path to abandoning desktop Access, but I don't think that's likely
to happen at all. It's conceivable for desktop Access to consist
entirely of the web forms/reports and have only macros and embedded
macros and no VBA, but I just don't see that as very likely, either,
since by doing that, they would basically have re-invented Filemaker
Pro, along with almost all the weaknesses of FM (insufficiently
extensible scripting being the primary lack).
Why would they do that?
More likely is replacement of VBA with some for of VB.NET, seems to
me, and that will likely be highly compatible (though not without
major feature sacrifices along the way, no doubt).
> I have no doubt that Microsoft would love us
> to move to .NET. What I saw at the time was that the direction
> Microsoft was headed was at odds with the existence of VBA. Like
> a politician, they decided to spread out the implementation time
> to make it more gradual. VBA may not be dead, but its heyday is
> over. My guesses were not as far-fetched as you imagined. I
> think your faith in VBA wasn't much better than my guesses.
Hmm. You said VBA was on the way out, but it's still there, with
more features than it had at the time of the quote you base this on.
It's fully supported.
You have to make the argument that something entirely unexpected,
the web integration with Sharepoint, is the reason VBA is on the way
out. Well, blind squirrels and stopped clocks and all that, but we
don't even know that is the case. I strongly doubt that MS will
eliminate a scripting language entirely in favor of macros. The
question is what that language will be. I am not so deluded to think
that it will always be VBA, but what I am certain of is that if MS
follows its historical path, whatever scripting platform they
replace VBA with will either be highly compatible, or it will have a
transparent and reliable transition path. Thus, VBA won't be
replaced with Javascript. It might be replaced with VBScript, but
VBScript *is* VB, so that would be no problem whatsoever.
Salad
> "Salad" <o...@vinegar.com> wrote in message news:7smdnZDD9->
>
>>Hi Albert. A2003. I logged into OfficeLive
>
>
> You need to use office live small business, office live does not have
> ms-access support.
>
> Here is a discussion and screen shots:
>
> http://www.utteraccess.com/forums/showflat.php?Cat=&Board=97&Number=1903007&Zf=&Zw=&Zg=0&Zl=a&Main=1886252&Search=true&where=&Zu=120391&Zd=l&Zn=&Zt=bd&Zs=&Zy=#Post1903007&Zp=
>
>
Thanks for the above link and data on hyperlinks. Now I have
SmallBusiness as well. I wouldn't have gotten this to work without that
information.
I created a small mdb; DB1.mdb with a junk table called Table1. From
OfficeLive, I created an apps area called Small Access Test. If I
attempt to upload the file within OfficeLive (by selecting Upload and
selecting DB1) I get an error. If I open DB1.mdb in Access and select
Table1 and do a file export of it to SharePoint and give the URL, it
loads Table1 into the application workspace. I then did a
File/GetExternalLink and linked to the file and it linked fine. It
created a file in the DB called Table1: All Items and it has a new field
in it called Edit which is a hyperlink field.
Does this seem to be the correct way of doing this? This was in Office
2003, A2007 is at work.
Albert D. Kallal
>
> It would be more compelling if there weren't already a way to make
> that separation and maintain consistency, i.e., a stored QueryDef
> with the derived field.
>
Quite true. however, you are then tied into using that querydef.
>> 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.
>
> Then it should be defined in a layer *above* the table, where it
> belongs.
Sure, a case can be made that this belongs in some other tier.
On the other hand if they come along and build some new service architecture
then I don't have necessary to communicate with that particular layer. As
long as the data is stored and enforced by the engine level, then it don't
matter what tier or service uses that data. In fact, any service can read
that data DIRECT and will have the correct result.
>
> And just to be clear, this *is* something that's both in Sharepoint
> and in the new version of ACCDB, right? That is, it's a new column
> type in Access?
Yes, correct, this is a new column type in ACE.
>
>> 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.
>
> That's what the middle tier is for.
As I mentioned, sure, but then again this is just a long time debate
as to if certain things belong in the software side, or at the data
side of things.
You might not want to be forced to use that middle tier.
With this system you don't have to care anymore. Any new system you build
can use that new data column. This kind of debate also been a long time sql
server debate and that of some saying one should avoid things like triggers
and stored procedures as they don't belong at engine level as opposed to the
application level.
There is a lot of pro's and con's in this debate, almost
Like those who debate between auto number primary keys, and that of natural
keys, there is a lot of differing opinions on this issue.
However, no matter which way people debate this issue, there is still some
advantages to be had for this approach and there is a chunk of the IT
industry that has adopted this Philosophical approach, especially for cloud
vendors.
>
> I would never recommend to my clients that they host anything
> important on such a service.
Unfortunately my opinion here does not really matter here or change what
consumers and business are doing. I not really giving my opinion here as
much as simply making an Observations as to how people are behaving.
Millions and millions of people use Gmail. Millions are now placing most if
not all of their business processes on systems like eBay. That means
pricing, inventory, sales, payment processing = everything they have is on
eBay, but they don't complain that it not on their own computer.
People are not listing to the recommends not to use cloud systems.
L.A. votes to "Go Google"; pressure shifts to Google and the cloud
http://blogs.zdnet.com/BTL/?p=26641&tag=nl.e539
I can get 100's of articles like the above in which county's and
municipalities and school districts on jumping on this bandwagon.
It not me you have to convince here,
it is the millions and millions of customers that choosing otherwise that
you have to convince. Many people did not believe in the advantages of the
GUI, and they not in this business anymore. This is not our choice, and the
boat left the harbor. As you point out, there still many applications that
are
green screen and were never converted. However, the GUI was not a fad.
That no question that there's tons of legacy green screen application left
over from that era, however we're not seeing you develop a new architectures
and there really no new industry work being created for those legacy green
screen applications. And, they don't solve any of the new business needs
either. The issue is not that there still some green screen applications
being used, or that some are still viable, they don't represent anything in
terms of creating new work or the future of our industry.
people by the millions are making the clout choice, it's not my decision to
make here.
> While software as service is going to fit certain kinds of
> companies, I think it is not going to fit a large number of them.
> Cloud computing
> by definition requires offline editing or it's useless (since you're
> dead in the water if the Internet is down)
Most business today generally shutdown without their phones, or without
electricity . In fact, most of my customers, if their internet is down, they
very much
can't work and tend to all go home...
>I've been heavily committed to Windows Terminal Server and
remote desktop access for a very, very long time, so perhaps my
clients have been getting the majority of the benefits from the
standpoint of access without using this particular buzzword
technology.
Yes, but on the other side, there not a architecture that scales to
millions of
users at a reasonable cost. Sure the customer side gets thin client with TS,
but on the supply side it would be far too expensive to have human labor to
setup the individual servers etc..
The "new" cloud operating systems such as
azure have the ability to censure, build and put on line computers with the
correct services you need. They do this dynamic in real time. So, they
tend to have a top level system called the "fabric controller" that goes out
to the millions of computers, and figures out which ones has the correct
services your
software needs. If your software needs some particular type of database
system such as sql server, then the top level management systems system
will go out and get the best available resources that are currently running,
and if they're not running, then it'll will start those services up on most
readily available computers.
Again, all this stuff is not a buzz word, it's a different way and different
architecture of doing things and accomplishing that goal which allows you to
deliver software as a service **and** supply those services at a very low
cost.
So, cloud computing is all about utility computing just like electricity
is). So, yes, TS has the benefits, but does not have an architecture that
truly scales like Amazon's , or Google, or now azure. Those systems are
built from the ground up to scale on demand.
Here some reading on Amazons service:
http://aws.amazon.com/ec2/
and, here is some on Azure:
http://en.wikipedia.org/wiki/Azure_Services_Platform
James A. Fortune
wrote:
> The quote is from a book that was published in 2002. This predates
You make some good points. I agree that the point in the book was
more hopeful than actual. The date of the book, although it weakens
the argument, still points to a plan to remove VBA from its pedestal.
Maybe it's like what has happened with parallel programming. The new
thought patterns required to implement parallel programming
efficiently are making older thought patterns passé. Thus, in
preparation for the emphasis on parallel programming inspired by
research and required by the resulting trend towards many-core CPU's,
some of the OOP concepts that worked great for single core processing
are starting to be maligned because they actually hinder the move to
parallelism. Although VBA is around as much as ever, and is still one
of the best RAD languages ever created, it will likely never receive
the bulking up that will be required to keep it from retaining many of
its current weaknesses. Microsoft would like Access to work without
having to resort to VBA at all, but we all know how much poorer Access
would be without VBA or some other scripting language. If the desktop
and the internet are to look essentially the same to Access, then VBA
has to be redone anyway. VBA limits Access to the desktop, and even
there it can be a security risk. In spite of how great VBA has been
for marvelously extending the capabilies of Access, I think
Microsoft's decision to let it die slowly of relative neglect is
probably a wise decision, yet one that will eventually cause me to
have to take much more time to write code.
James A. Fortune
CDMAP...@FortuneJames.com
Albert D. Kallal
> If I attempt to upload the file within OfficeLive (by selecting Upload and
> selecting DB1) I get an error.
The above is not for putting up access,but is for simply placing word,
pictures, pdf files etc. Not sure what you doing or why a simply file upload
fails, but this is has nothing to do with up-loading a list/table to
SharePoint.
If I open DB1.mdb in Access and select
> Table1 and do a file export of it to SharePoint and give the URL, it loads
> Table1 into the application workspace. I then did a File/GetExternalLink
> and linked to the file and it linked fine. It created a file in the DB
> called Table1: All Items and it has a new field in it called Edit which is
> a hyperlink field.
>
> Does this seem to be the correct way of doing this? This was in Office
> 2003, A2007 is at work.
Yes, in 2007, you can also do a up-size, and it will up-load the table +
build a link in one step. Also, 2007 supports off-line mode. So, the feature
set feels similar to sql server, you can use export to push up a table, but
also I often use the sql up-size wizard to push up a table to sql server
since it saves the step of having to do the file->external data link. So,
yes, the above is how this works..but 2007 is quite a bit nicer in this
regards.
David W. Fenton
:
> In spite of how great VBA has been
> for marvelously extending the capabilies of Access, I think
> Microsoft's decision to let it die slowly of relative neglect is
> probably a wise decision, yet one that will eventually cause me to
> have to take much more time to write code.
I think this "decision" of which you speak is a complete figment of
your imagination.
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CC2905F22C6Df9...@74.209.136.100...
>
>> I would never recommend to my clients that they host anything
>> important on such a service.
>
> Unfortunately my opinion here does not really matter here or
> change what consumers and business are doing. I not really giving
> my opinion here as much as simply making an Observations as to
> how people are behaving.
>
> Millions and millions of people use Gmail.
Not real businesses, just individuals. And I think it's a bad idea,
since despite there "do no evil" pledge, they still have access to
the data and can do all sorts of things they might not be "evil"
from their point of view, but which might not align with the
interests of their users.
> Millions are now placing most if
> not all of their business processes on systems like eBay. That
> means pricing, inventory, sales, payment processing = everything
> they have is on eBay, but they don't complain that it not on their
> own computer.
I don't know what you're talking about with regard to eBay, but I'm
not suggesting there aren't things to be gained by moving certain
kinds of applications out of the local net and onto the Internet. I
would only question whether the benefits are worth the risks that
come with it. Right now, I don't think they are. That balance will
likely change someday, but I don't know if it will be sooner or
later.
And certain kinds of applications don't benefit at all from being
moved out of the local network and onto the Internet and never will.
I know you're not claiming that they will, but I don't think the
proportion of applications for which there's real benefit in moving
to the cloud is not nearly as large as the promoters of the hype
would have us believe.
> People are not listing to the recommends not to use cloud systems.
>
> L.A. votes to "Go Google"; pressure shifts to Google and the cloud
> http://blogs.zdnet.com/BTL/?p=26641&tag=nl.e539
>
> I can get 100's of articles like the above in which county's and
> municipalities and school districts on jumping on this bandwagon.
There are 1000s of articles on Web 2 and it's just a buzzword that
most of the people using it don't really understand, and that at
base really only describes an incremental change in available
functionality.
Then there's all the hype about social networking and such. I don't
recall if you specifically responded, but when I posted that I was
trying out Twitter, it resulted in a lot of folks in the Access
newsgroups declaring how useless it was and how they'd never use it.
And yet, I see Tony Toews using it regularly. I don't know if any
other Access programmers are, though (I just have an RSS feed to
monitor the hash tag #access, which turns up a lot of non-Access
related things, but also turns up lots of relevant comments).
The point is: if you believed half they hype you'd think that 75% of
us were using social networking tools.
They aren't.
It's all hype.
I think "cloud computing" is also mostly hype. Sure, there are some
obvious uses for it for certain kinds of organizations. But the
kinds of companies that depend on Access are mostly not the type
that need or desire either the benefits or the risks that come with
it.
> It not me you have to convince here,
> it is the millions and millions of customers that choosing
> otherwise that you have to convince. Many people did not believe
> in the advantages of the GUI, and they not in this business
> anymore. This is not our choice, and the boat left the harbor. As
> you point out, there still many applications that are
> green screen and were never converted. However, the GUI was not a
> fad.
Until widespread use of AJAX, most browser-based apps were only a
step above green screen in terms of either how they worked (the
client was just as much a dumb terminal as in the old days) or the
UI offered. Certainly AJAX has vastly expanded the possibilities for
UI richness and responsiveness, but these apps are still primitive
in comparison to what desktop apps have offered for a very long
time. It just seems like a big deal because it's such a quantum leap
over the primitive interfaces possible before AJAX became viable
(i.e., when the old browsers were replaced by new ones, which
basically means getting rid of IE before IE7; all the other browsers
were there years before IE7).
> That no question that there's tons of legacy green screen
> application left over from that era, however we're not seeing you
> develop a new architectures and there really no new industry work
> being created for those legacy green screen applications. And,
> they don't solve any of the new business needs either. The issue
> is not that there still some green screen applications being used,
> or that some are still viable, they don't represent anything in
> terms of creating new work or the future of our industry.
The way I see it is that there are not a lot of mainline business
apps that benefit from the new capabilities. A billing application
really doesn't need HTML 5's support for embedding video, for
instance. A heavy-duty data entry application doesn't need much in
the way of graphics support -- it just needs to be fast for a human
being to type in the data and type it in accurately.
A lot of the business apps out there are still of that type. Now,
certainly, things like Google Wave are creating new application
paradigms, but those are mostly in the communication sphere. That
is, Google Wave is a collaboration and communication platform, which
is very different from the kinds of apps that have existed in the
past.
But those older apps aren't going to be replaced by Google Wave-like
apps because the tasks those older apps are designed to perform are
not going to be enhanced in any way by the capabilities these new
applications/platforms offer.
> people by the millions are making the clout choice, it's not my
> decision to make here.
I don't think there are nearly as many people doing that as you
think.
>> While software as service is going to fit certain kinds of
>> companies, I think it is not going to fit a large number of them.
>
>> Cloud computing
>> by definition requires offline editing or it's useless (since
>> you're dead in the water if the Internet is down)
>
> Most business today generally shutdown without their phones, or
> without electricity . In fact, most of my customers, if their
> internet is down, they very much
> can't work and tend to all go home...
My clients can still operate without the Internet, certainly not as
well or as flexibly, but it doesn't shut them down. If their main
apps were in the cloud, they likely *would* be dead in the water,
even with offline editing.
It just seems obvious to me that computing should be largely local
and not concentrated in large hosts across a thin wire. It looks
like common sense to me.
>>I've been heavily committed to Windows Terminal Server and
> remote desktop access for a very, very long time, so perhaps my
> clients have been getting the majority of the benefits from the
> standpoint of access without using this particular buzzword
> technology.
>
> Yes, but on the other side, there not a architecture that scales
> to millions of
> users at a reasonable cost.
But Access developers are not in that sphere in the first place.
Even when an Access developer is working for a large company, very
seldom is she maintaining any apps that are used by more than a
handful of people. Enterprise software is just not the place where
Access is appropriate, and I don't see why solving scalability
problems at that level should be something I should give a rat's ass
about, let along cheer as something great for the future of Access.
> Sure the customer side gets thin client with TS,
> but on the supply side it would be far too expensive to have human
> labor to setup the individual servers etc..
Who cares? I don't work for companies who have 1000s of employees,
nor even 100s. Why should I be excited about a technology that
solves a problem that my clients will never, ever under any
circumstances encounter?
[hype about Azure deleted]
> Again, all this stuff is not a buzz word,
I'm sorry, but the dreck you just posted about Azure pretty much
demonstrates that it really is a bunch of marketing-speak and not
something real that solves actual problems that the clients of
Access developers have.
> it's a different way and different
> architecture of doing things and accomplishing that goal which
> allows you to deliver software as a service **and** supply those
> services at a very low cost.
I don't have a single client who wants to pay for their mainline
software as a service. They want to buy it and install it on their
computers and use it until the point that they decide they want to
replace it. They don't want some outside dependency. They don't want
subscription fees. They don't want automatic upgrades that make
their apps work differently, or take away functionality they like,
or introduce show-stopping bugs.
> So, cloud computing is all about utility computing just like
> electricity is). So, yes, TS has the benefits, but does not have
> an architecture that truly scales like Amazon's , or Google, or
> now azure.
And I don't give a rat's ass. Nor do my clients.
> Those systems are
> built from the ground up to scale on demand.
And I don't care. And I don't think small businesses are going to
benefit in the way you suggest. I also doubt that it's ever going to
live up to they hype even for the enterprise-level organizations.
David W. Fenton
http://www.theregister.co.uk/2009/11/15/trusting_cloud_storage/
http://www.theregister.co.uk/2009/11/15/rackspace_no_more_servers/
The first article doesn't have the payoff it promises in the first
page, and only deals with the storage aspect of cloud computing and
not the software-as-service part of it, but most software-as-service
applications will be storing data in the cloud, too, so it's an
aspect of the issue.
The second article is about how much sysadmins hate administering
servers. I don't get this one, but I've never been involved in a
huge organization, only ones where there were half a dozen servers
at most (each for a different purpose).
That just sort of makes the point I was making elsewhere, that
enterprise-level organizations have different issues than small
businesses (and I would say any business with under 100 employees is
a small business).
Food for thought/fodder for discussion.
James A. Fortune
wrote:
> "James A. Fortune" <CDMAPos...@FortuneJames.com> wrote innews:a2d9cea4-4e83-43b1...@u7g2000yqm.googlegroups.com
> :
>
> > In spite of how great VBA has been
> > for marvelously extending the capabilies of Access, I think
> > Microsoft's decision to let it die slowly of relative neglect is
> > probably a wise decision, yet one that will eventually cause me to
> > have to take much more time to write code.
>
> I think this "decision" of which you speak is a complete figment of
> your imagination.
I think that the many PDC 09 sessions covering all the great new plans
for VBA are a figment of your imagination.
James A. Fortune
CDMAP...@FortuneJames.com
"...the Droid can get e-mail from an Exchange server that does not use
ActiveSync policies..." -- http://www.infoworld.com/d/mobilize/deathmatch-motorola-droid-versus-iphone-566
Albert D. Kallal
Sorry, about leaving this..I was sick for a day..and really got behind as a
result...
however, tehre is few points to make her:
>>
>> Millions and millions of people use Gmail.
>
> Not real businesses, just individuals.
Actually, there is very large number of auto dealers, equipment sales and
companies with 100's of employees that sell things on eBay. It not just all
individuals .
There also popular CRM systems like sugarCrm that are cloud based.
> And I think it's a bad idea,
> since despite there "do no evil" pledge, they still have access to
> the data and can do all sorts of things they might not be "evil"
> from their point of view, but which might not align with the
> interests of their users.
I will say that most, if not all of the cloud based offerings from Microsoft
are better than the competition in that most allow offline mode (the
purchase of grove networks was the reason for this ability).
And, keep in mind that a significant portion of email users don't "host"
their own e-mail servers. This is not a business solution for everything,
but do keep in mind the concept of cheap and easy and available, it tends
win in the marketplace...
>> People are not listing to the recommends not to use cloud systems.
>>
>> L.A. votes to "Go Google"; pressure shifts to Google and the cloud
>> http://blogs.zdnet.com/BTL/?p=26641&tag=nl.e539
>>
>> I can get 100's of articles like the above in which county's and
>> municipalities and school districts on jumping on this bandwagon.
>
> There are 1000s of articles on Web 2 and it's just a buzzword that
> most of the people using it don't really understand, and that at
> base really only describes an incremental change in available
> functionality.
don't confuse a fundamental architecture change in our industry, to that of
buzzwords and hype
>
> Then there's all the hype about social networking and such. I don't
> recall if you specifically responded, but when I posted that I was
> trying out Twitter, it resulted in a lot of folks in the Access
> newsgroups declaring how useless it was and how they'd never use it.
twitter and social networking is not a fundamental engineering problem that
our computer industry is attempting to solve by adopting these new
technologies. perhaps some of the social networking saw the result of
adoption this new technology, but at the end of the day twitter is not an
engineering solution for access or software developers.
>
> The point is: if you believed half they hype you'd think that 75% of
> us were using social networking tools.
>
> They aren't.
>
> It's all hype.
you have to distinguish between fundamental architecture designs and how we
build software, and that of hype, let me explain:
In the mid nineteen eighties bill gates was talking about this concept of
software becoming a component, or reusable application that you can plug
into other applications. Most people thought it was hype. Most people
thought it was crazy.
Then, all the buzz words came out...OLE, activeX, com (they all mean the
same thing).
The result of a whole above issue who was that of what we call "com" or so
called object automation (in fact the names been changed over the years, and
is at one time refer to as OLE, or activeX).
The critical concept, or thing to keep in mind was ONCE applications that
were written to the com object model meant that other applications would be
able to automate or use an application.(are never dare this time period, and
often clients of mine who would ask me to choose some contact manager from
Symantec, or from Maximizer, I always had them purchase the one that could
be "automated". You see, back then, not all software could be used as a com
object).
In fact, when I read papers about this new future, I can remember some years
later the exact place and time when I was in a store reading about the new
version of office that would allow the components to be used in your code.
Furthermore the prediction of a bunch of software vendors springing up to
sell you re-usable components that you could use off the shelf also
occurred. Now you can purchase a great grid control, or calendar control,
or one of my favorite list controls from bennet-tec here:
http://www.bennet-tec.com/products.htm
So, that future was correct, but that future could not occur tell the basic
building blocks and underlying technologies in the industry had changed!
(that is what is occurring right now with cloud systems).
In fact when I read about these future technologies, at the time I was
working in a mainframe system that allowed my code to automate a word
processor and spreadsheet, I realized if that technology is coming to the
desktop, then I going to get into the computer software business. So
reading about that fundamental change in technology is what got me into the
desktop side of this computer industry!
When access came out and 91 and 92, it was developed around OLE technologies
that Microsoft had been developing and working on for about eight years.
Compared to products like FoxPro at the time, the separation of the data
engine from the programming language was a critical concept in the success
of access. It also the result of the architecture and design that MANY years
later allow access to adopt ADO. FoxPro in that same time had to be
completely reengineer to separate out the date engine parts. so, it turns
out that the fundamental investments in those technologies paid out big time
about 8-9 years later.
We see exactly the same thing with the investments in .net that happened
years ago, people don't understand the fundamental change in the basic
technology and how we're building software that occurred.
>> Google xml and web services and soap....
>That still doesn't tell me anything useful. Sounds like just another
buzzword.
You failing to distinguish between some fad like twitter and the underlying
underpinnings of our software industry.
Soap, or so called "web services" is really important. Just like "com" was
critical and instrumental to the success of access, and gave it a long jump
and long life, when you're developing with .net, and you set up a reference
to a web service, all of the web sites properties and methods of that web
site now become available as property and methods in your code. In a sense,
"soap" or a "web service" is like a com object automation for the desktop
top.
If I write an application in ms-access that uses word + outlook, then I am
automating several applications. In "web land", they even have a name for
when you use several web services, and it called a mash up. So this is
really the same concept of OLE, ActiveX, com but now is or the web.
And, guess what transport format is used when you talk to those web objects?
(we don't call them web objects, but we could/should have called them that,
since that we what we call these things on the desktop land). So, for the
web, we call this web services (or soap).
Anyway, the typically messaging formatted used to shuffle data from that web
service to the client? Well, goooly...it is XML!
So, soap, and xml are not a fad or a buzzword like twitter is. They are
fundamental building blocks that our industry adopted that allows software
to consume a web service just like ms-access developers might consume or
automate word or outlook.
So many said that OO was a fad. Today there is simply not a modern
development language right now being produced by any software vendor that is
really not an OO language. in fact I think the only popular widespread
development platform that's not OO these days is ms-access!
>
> Until widespread use of AJAX, most browser-based apps were only a
> step above green screen in terms of either how they worked
I agree, and it takes a bit of time for fundamental technologies to come all
together to make something really happen in our industry. AJAX is also what
allows access web services to work and produce beautiful running
applications in the browser.
>
>>>I've been heavily committed to Windows Terminal Server and
>> remote desktop access for a very, very long time, so perhaps my
>> clients have been getting the majority of the benefits from the
>> standpoint of access without using this particular buzzword
>> technology.
>>
>> Yes, but on the other side, there not a architecture that scales
>> to millions of
>> users at a reasonable cost.
>
> But Access developers are not in that sphere in the first place.
Ah, excellent....
Keep in mind that these cloud based operating systems don't have a bunch of
people running around installing software on them. All you'll see is a
loading dock with forklifts pulling servers in and out all day long. New
ones for additional capacity, and on the way out are ones that had a
problem. There's no people running around actually installing or setting up
software on those servers...
> Even when an Access developer is working for a large company, very
> seldom is she maintaining any apps that are used by more than a
> handful of people.
Just like I said the investments in access in the early 90's produced a
product that had a VERY long run in our industry, the access web services
are based on a cloud computing model. (this is **significant ** for several
reasons).
just like we know that access on a file share doesn't work well over a wan,
the fact that I told you access services is based on a cloud computing model
will instantly tell you that they will be limitations and certain kind of
applications that will not work well. (I'll save my answers in this regards
for another post to keep this thing a bit short).
>
> Who cares? I don't work for companies who have 1000s of employees,
> nor even 100s. Why should I be excited about a technology that
> solves a problem that my clients will never, ever under any
> circumstances encounter?
Why should you have been excited by com objects then? Did have to get
excited about it? No, but you sure as the heck been using this technology
from day one with access.
At the end of the day, you have to ask WHAT is the fundamental issue or
problem that these new technologies are solving. The answer to this question
gives you the answer as to whether it's a fad or not.
so, soap or web services + xml was used to bring the "com object"
programming paradigm to allow developers to consume applications that run
on web servers. .net was not a fad, and the whole concept of web services is
not a fad either.
>> Again, all this stuff is not a buzz word,
>
> I'm sorry, but the dreck you just posted about Azure pretty much
> demonstrates that it really is a bunch of marketing-speak and not
> something real that solves actual problems that the clients of
> Access developers have.
It's a significant issue for access developer's if you want to build web
sites using access, and want cheap affordable and widely available services
in the web in which to push those applications onto.
Having a bunch of guys running around maintaining some servers and using
terminal services is not going to compete with Google, or Amazon's
offerings. Cloud computing is all about utility computing, and the
architectures they've adopted allows many users at a very low cost.
Unfortunately the cost of is an major determining factor in this success in
the marketplace. The issues is not does your customer need a web site. The
issue is what technologies are they going to use to run the website, and
what software is going to run on the web site, and who's going to pay to
maintained that server and that software that's running -- that's what cloud
computing is all about...
>
> I don't have a single client who wants to pay for their mainline
> software as a service.
No, but you can't tell me none want to run a web site? None want to start
placing some parts of their business applications on the web? It too
expensive to set these things up on a server by a customer by customer
basis...
There's no question that some companies will want their own web server, but
the vast majority of my clients and customers simply don't want bothered
with setting up a web server to run that software.
It will be most interesting to look back at this posting five years from
now. The issue here is an fundamental change in fundamental technologies
that are being use to deliver software. It'll take a couple more years for
most people's understanding grasp what is going on here, but what's going to
happen will happen and it's unstoppable. The change here is very much like
"com", and it took about 8 years for the results of "com" in the industry to
become a mainstream fundamental part of our industry...the same goes for
these cloud systems, and the same happened for web services....
The boat has left the harbor on this..the industry is investing full speed
into these technologies, and they will become commonplace in the years to
come.
Albert D. Kallal
news:0fa5b88d-cc5e-44bd-b001-
>
> I think that the many PDC 09 sessions covering all the great new plans
> for VBA are a figment of your imagination.
>
Well, there is not really that many sessions on office applications at pdc,
but we are receiving a 64bit Version of VBA....
No question that receiving 64 bit version of access + VBA is certainly a big
hunk of money to spend on something with no future..
James A. Fortune
<PleaseNOOOsPAMmkal...@msn.com> wrote:
> "James A. Fortune" <CDMAPos...@FortuneJames.com> wrote in message
That's good news Albert. I like VBA. It's good that something is
being done. However, it's obvious to me that VBA does not have the
level of prominence it once had. I think that the phrase I used --
relative neglect -- is still quite accurate. I don't see that
changing. IMO, without us doing something like enhancing VBA
with .NET functionality, VBA will soon have too many weaknesses for it
to keep Access in its present role as a fairly serious development
tool. Maybe Microsoft has future plans for dealing with the VBA
weaknesses. Let's hope so. Lack of a 64 bit development environment
was certainly one of the weaknesses. I will continue looking into
enhancing Access throught .NET, even if it means that some of the work
I do will be nullified because of new enhancements by Microsoft,
because I will get the new features I want regardless of what features
Microsoft decides to add. Plus, some of the new features can even be
retrofitted into older versions of Access. Microsoft gave us new
possibilities by creating and distributing the .NET Framework, and I
intend to implement some of those new capabilities within Access.
James A. Fortune
CDMAP...@FortuneJames.com
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>
> Sorry, about leaving this..I was sick for a day..and really got
> behind as a result...
>
> however, tehre is few points to make her:
>
>>> Millions and millions of people use Gmail.
>>
>> Not real businesses, just individuals.
>
> Actually, there is very large number of auto dealers, equipment
> sales and companies with 100's of employees that sell things on
> eBay. It not just all individuals .
Uh, you respond to a point about GMail with an answer about eBay?
> There also popular CRM systems like sugarCrm that are cloud based.
Cloud-based, or just hosted?
This is one of the things that indicates to me that "cloud" is a
buzzword, i.e., that it gets used for all sorts of things that have
always existed.
>> And I think it's a bad idea,
>> since despite there "do no evil" pledge, they still have access
>> to the data and can do all sorts of things they might not be
>> "evil" from their point of view, but which might not align with
>> the interests of their users.
>
> I will say that most, if not all of the cloud based offerings from
> Microsoft are better than the competition in that most allow
> offline mode (the purchase of grove networks was the reason for
> this ability).
But it was a Microsoft subsidiary that had had the most spectacular
incident of losing customer data.
> And, keep in mind that a significant portion of email users don't
> "host" their own e-mail servers.
But it is logical for email to be hosted outside your office because
it's a communications platform. It is perfectly logical that
services that involve communication across the Internet be hosted on
the Internet rather than on your local LAN.
> This is not a business solution for everything,
> but do keep in mind the concept of cheap and easy and available,
> it tends win in the marketplace...
I'm not saying there aren't applications where it is a good
solution. I'm only saying that you are overselling it. I have no
clients that would benefit from moving their mainline applications
to hosted solutions. The part that needs to be hosted (email,
website) is already hosted. The parts that aren't don't benefit from
being moved to the Internet.
>>> People are not listing to the recommends not to use cloud
>>> systems.
>>>
>>> L.A. votes to "Go Google"; pressure shifts to Google and the
>>> cloud http://blogs.zdnet.com/BTL/?p=26641&tag=nl.e539
>>>
>>> I can get 100's of articles like the above in which county's
>>> and municipalities and school districts on jumping on this
>>> bandwagon.
>>
>> There are 1000s of articles on Web 2 and it's just a buzzword
>> that most of the people using it don't really understand, and
>> that at base really only describes an incremental change in
>> available functionality.
>
> don't confuse a fundamental architecture change in our industry,
> to that of buzzwords and hype
Good advice. Please take it to heart, Albert. You're using "cloud"
in a very loose fashion and you're claiming more for it than almost
anyone I've read anywhere. You're doing the buzzword dance as hard
as anyone I've encountered and it damages your credibility, in my
opinion.
>> Then there's all the hype about social networking and such. I
>> don't recall if you specifically responded, but when I posted
>> that I was trying out Twitter, it resulted in a lot of folks in
>> the Access newsgroups declaring how useless it was and how they'd
>> never use it.
>
> twitter and social networking is not a fundamental engineering
> problem that our computer industry is attempting to solve by
> adopting these new technologies. perhaps some of the social
> networking saw the result of adoption this new technology, but at
> the end of the day twitter is not an engineering solution for
> access or software developers.
In the period 1990-95 or so, it was all about thin clients, which
was a solution to "a fundamental engineering problem" for the
computer industry. It never happened (or, at least, only in a
limited fashion, and not at all in the way it was originally
conceived of -- we run thin client applications on fat client
hardware, but the thin client hardware never really materialized).
Also, the "fundamental engineering problem" you adduce is one that
is much bigger a deal for large companies than for small. I don't
work for big companies (I don't want to!), and so their needs are
not of much interest to me. In fact, their needs and interests often
make my life *worse* -- consider the butchering of Access 2000 that
was almost all because of MS's desire to make Access more
enterprise-friendly. Or consider the stupidity of the security
warnings in Office combined with no global solution that is
appropriate to anything but large businesses.
When the interests of large companies drive the deveopment of the
platforms from which I make my living, my life is made *harder*.
Thus, you might understand my skepticism about the whole "cloud"
thing.
I surely see the value in the new level of Sharepoint integration in
A2010 -- it's the first version of Sharepoint that I can actually
see could have benefits for some of my clients.
But that seems to be too small-scale for you. You're not happy with
that, you seem to need to push the bigger picture, and I think
you're overclaiming in that regard, and that could discredit your
closely focussed comments about A2010/Sharepoint.
[]
>>> Google xml and web services and soap....
>
>>That still doesn't tell me anything useful. Sounds like just
>>another
> buzzword.
>
> You failing to distinguish between some fad like twitter and the
> underlying underpinnings of our software industry.
You think Twitter is a fad? I don't. Now, maybe Twitter itself won't
survive, but what Twitter represents is being integrated into all
sorts of places across the web. It's becoming a service that is
being embedded in all sorts of social networking and blogging sites.
And that includes serious ones, like LinkedIn, not just "hobby"
sites.
It's one of the real platforms behind the buzzwords.
You're spouting buzzwords now, when I think it would be better for
you to spend your time talking about the real platforms that you see
as fitting under the umbrella of the buzzwords.
[]
> So many said that OO was a fad.
And a lot of what has been written about OO is gibberish and hype.
And people still subscribe to a lot of OO-for-its-own-sake ideas,
seems to me.
> Today there is simply not a modern
> development language right now being produced by any software
> vendor that is really not an OO language. in fact I think the only
> popular widespread development platform that's not OO these days
> is ms-access!
I don't feel we lack anything that real OO would help us with. It
would just make things more complicated.
OO has always looked like the emperor with no clothes to me, at
least in the form advocated by the purists. Sure, it brought a lot
of useful stuff into mainstream programming, and that's good, but
you don't need pure OO to get the benefit of using objects and
defining your interfaces and being able to instantiate multiple
instances and so forth. All of those things we can do in Access
without full OO, and that's fine because those are the things we
really need to build database applications, and we don't really need
the more complicated aspects of OO (not that we could never need
them, just that we wouldn't benefit from them often enough to
justify the added complexity).
[]
>> Who cares? I don't work for companies who have 1000s of
>> employees, nor even 100s. Why should I be excited about a
>> technology that solves a problem that my clients will never, ever
>> under any circumstances encounter?
>
> Why should you have been excited by com objects then?
Because it was immediately obvious to me when Office 97 came out
that here was a platform that would allow small businesses to build
complex, rich custom applications on top of the Office platform for
a fraction of what it would cost to build the same functionality
from scratch.
I was HUGELY excited about full COM in Office during that time frame
because it exactly fit the needs of small businesses, who couldn't
afford to buy huge apps that cost $100K but also couldn't afford to
program from scratch all the functionality they needed. The Office
platform enabled a whole new set of possibilities for those small
businesses.
> Did have to get
> excited about it? No, but you sure as the heck been using this
> technology from day one with access.
I think your timeline is a bit foggy. Yes, COM was underneath Office
in the c. 1992-94 time frame, and MS was implementing what they
called OLE, because the main thing they were providing was ability
to embed objects, a spreadsheet in Word, a graph in Excel or Access.
But this was nothing close to the automation capabilities that would
come once VBA was integrated into all the Office apps. That came
with Office 95, quickly followed by Office 97 as the bug fix for it
(and remember that Access 95 was not shipped with the rest of Office
95 -- it came out only a year later, Fall of '96).
> At the end of the day, you have to ask WHAT is the fundamental
> issue or problem that these new technologies are solving. The
> answer to this question gives you the answer as to whether it's a
> fad or not.
But the question I'm asking is:
Is it useful for *me*? (i.e., me and my clients)
And I'm simply not convinced that "cloud" computing is going to be
all that helpful to small businesses.
[]
>>> Again, all this stuff is not a buzz word,
>>
>> I'm sorry, but the dreck you just posted about Azure pretty much
>> demonstrates that it really is a bunch of marketing-speak and not
>> something real that solves actual problems that the clients of
>> Access developers have.
>
> It's a significant issue for access developer's if you want to
> build web sites using access, and want cheap affordable and widely
> available services in the web in which to push those applications
> onto.
And if you don't, it's not a significant issue.
D'oh.
That's precisely my argument -- that you're asserting that it's
important when that remains to be seen.
It's not that I don't believe a lot of large companies will be
moving to software services and data storage in the cloud. I simply
question how ubiquitous it's going to be, and right now everybody's
running around with their hair on fire claiming that everything will
be in the cloud one day.
You might call that the Strong Theory of Cloud Computing.
I reject that in favor of the Weak Theory of Cloud Computing, i.e.,
that many large companies will move certain kinds of applications
and data into the cloud, and some small businesses will find benefit
from moving some of their apps to hosted solutions.
Perhaps after I'm dead, it will all be in the cloud, but I don't
expect to see it within my working lifetime (or even within my
lifetime).
[]
>> I don't have a single client who wants to pay for their mainline
>> software as a service.
>
> No, but you can't tell me none want to run a web site?
Most of my clients already have websites, which, like email, is an
"application" that should naturally be hosted, by virtue of what it
is, i.e., a public-facing communications application.
> None want to start
> placing some parts of their business applications on the web?
While none of my current clients want to do that, I have certainly
had clients who might have wanted a limited web interface to their
database application for their customers.
But it seems to me that utilizing Access to build that is
problematic. It means maintaining two separate Access front ends,
one for publishing the website, and one for the in-office users.
Could it be done to keep both parts in one front end and publish
only the parts that were publishable? Sure, but I'd expect it to be
more trouble than it's worth.
At that point, the question becomes whether or not it's worth tying
yourself to Access and Sharepoint for your customer-facing web
interface. And it's not clear to me that it's a viable long-term
choice because it's way to early. The possibility is there, but I
don't know what the implications are for the long run, or what the
daily realities of maintaining such an app might very well be.
> It too
> expensive to set these things up on a server by a customer by
> customer basis...
>
> There's no question that some companies will want their own web
> server, but the vast majority of my clients and customers simply
> don't want bothered with setting up a web server to run that
> software.
????
I don't know what issue you're addressing here.
[]
> The boat has left the harbor on this..the industry is investing
> full speed into these technologies, and they will become
> commonplace in the years to come.
Go back and read about offshore outsourcing 5-10 years ago. It's
embarassing and a lot of companies that offshored services have
brought them back. Many still use offshore outsourced service
providers, but the whole hog offshoring didn't work out -- only some
subsets of services could be successfully outsourced offshore, and
those that worked have stayed there, and those that didn't have come
back.
I expect exactly the same thing, i.e., claims today that everything
will soon be in the cloud, followed by a mad dash to stick
everything in the cloud, and then a retrenchment after people
discover that in a lot of cases, it wasn't a very sound idea to
begin with, while in others it will work just great.
You seem to me to be at the overpromising/overclaiming stage in
regard to cloud computing. You are in good company in that regard,
since Microsoft and Google and the entire computer press are all
doing the same thing.
But it won't pan out the way they claim.
It will be much less significant than they forecast, which is not to
say it will be insignificant.
It will just not be as game-changing as the marketers would like us
to believe.
Albert D. Kallal
>> Actually, there is very large number of auto dealers, equipment
>> sales and companies with 100's of employees that sell things on
>> eBay. It not just all individuals .
>
> Uh, you respond to a point about GMail with an answer about eBay?
>
Not my intention to sidetrack that issue, however it doesn't really matter
either way, it's a question of consuming some hosted service somewhere,
gmail, or ebay don't really matter in this context..
>> There also popular CRM systems like sugarCrm that are cloud based.
>
> Cloud-based, or just hosted?
>
Ah..good! It is really fantastic of you to make the point/issue out of cloud
based vs. hosted, I most certainly guilty of doing this, and yet here I am
tooting a horn about how one REALLY wants to distinguish that cloud
computing is significantly different than that of a hosted system. It
certainly is. Its like so many calling access the database, and they're
talking about jet, this distinction is important here.
If you develop a software package for these cloud operating systems, that
"install" package" is really very much like a msi install package for the
windows desktop. This package can then be deployed to that particular cloud
operating system. Once you give that package (application) to that cloud
system, the OS takes over and does all the magic for you (such as
requisitioning servers, gathering needed components such as the database
servers etc.)
> This is one of the things that indicates to me that "cloud" is a
> buzzword, i.e., that it gets used for all sorts of things that have
> always existed.
>
> I'm not saying there aren't applications where it is a good
> solution. I'm only saying that you are overselling it. I have no
> clients that would benefit from moving their mainline applications
> to hosted solutions.
Yes, I again much agree with you here. As I said some of these people who
move all their business systems and processes to hosted (or cloud) systems
are likely pushing things too far for my tastes. However, as I mentioned a
lot of people don't always do the best thing, and there is that savings of
$$ issue.
Some people don't maintain their cars well, and I've seen some businesses
with some pretty crappie delivery trucks. Others have beautiful drop dead
gorgeous delivery trucks. Fact is some businesses don't always do the best
thing. However for a lot of businesses, cheaper and less cost = simply
better this happens all too often..
>>
>> twitter and social networking is not a fundamental engineering
>> problem that our computer industry is attempting to solve by
>> adopting these new technologies. perhaps some of the social
>> networking saw the result of adoption this new technology, but at
>> the end of the day twitter is not an engineering solution for
>> access or software developers.
>
> In the period 1990-95 or so, it was all about thin clients, which
> was a solution to "a fundamental engineering problem" for the
> computer industry. It never happened (or, at least, only in a
> limited fashion, and not at all in the way it was originally
> conceived of -- we run thin client applications on fat client
> hardware, but the thin client hardware never really materialized).
Actually there's quite a few vendors that created thin clients. However, if
you want to know why thin client computing such as terminal services was
never going to be mainstream or a huge success, all you had to do was ask me
7 years ago, and read the following article of mine:
Why bother with .net when you have Thin Client?
http://www.members.shaw.ca/AlbertKallal/Articles/ThinClientsand.net.html
(you don't have to go and read it).
To make a long story short, I explain in that article 7 years ago why.net's
going to be a better choice than thin client. The reason was simple and that
is that terminal services did not solve some of the fundamental problems
that we developers needed to be solved when we develop software. so, again,
as I said, if you ask the right questions, then you can tell if something
being pushed is going to be a success or not...
>
> But that seems to be too small-scale for you. You're not happy with
> that, you seem to need to push the bigger picture, and I think
> you're overclaiming in that regard, and that could discredit your
> closely focussed comments about A2010/Sharepoint.
Actually, my point was I think for the smallest of businesses we now can
move some line of business things (that should be moved by the way!) to the
web. We are going to benefit as much if not more then the larger businesses
that already has invested in these huge IT infrastructures to provide those
web systems and line of business applications for their customers.
With cloud computing, we will now be able to develop and offer web solutions
to our customers at an affordable cost - both hosting wise, and both
development cost wise. If we write to that particular cloud operating
system, then things like database servers, even payment processing and email
marketing systems will simply be components and services that we can include
into our applications (just like we include things like word and outlook now
into our desktop applications).
So the way I see this cloud thing is that it helps the smaller developers
and opens up more development opportunities for us. The big companies
already spent the huge amounts of money to on their web systems and customer
web portals. I really do think we smaller developers stand the most to gain
here.
>>
>> You failing to distinguish between some fad like twitter and the
>> underlying underpinnings of our software industry.
>
> You think Twitter is a fad? I don't. Now, maybe Twitter itself won't
> survive, but what Twitter represents is being integrated into all
> sorts of places across the web. It's becoming a service that is
> being embedded in all sorts of social networking and blogging sites.
> And that includes serious ones, like LinkedIn, not just "hobby"
> sites.
I should clear this up. Twitter may be a fad, may not be a fad, my WHOLE
point here is that twitter is not some architecture or computer technology
like XML, OO, or ole/com that is part of our development process when we
write software. That what I meant by fad vs. underlying architecture for
software, not to really state twitter is a fad or not.
>
> I don't feel we lack anything that real OO would help us with. It
> would just make things more complicated.
>
We do have class objects, so we have some OO bits. I would like to see a web
services consumption ability built right into access. (there was a soap
add-in tool for access/office 2003, but I did not like how it worked).
>
> At that point, the question becomes whether or not it's worth tying
> yourself to Access and Sharepoint for your customer-facing web
> interface. And it's not clear to me that it's a viable long-term
> choice because it's way to early. The possibility is there, but I
> don't know what the implications are for the long run, or what the
> daily realities of maintaining such an app might very well be.
I actually agree with you on the above quite a bit. Having played with the
system, I don't think the problem of having client forms and web forms the
same application is really a problem.
However, In the case of access web services, if the many widespread hosting
options don't spring up (there are many SharePoint hosters for less then $20
a month), and in addition my assumption of the free officelive versions
don't pan out, then this will not be cheap and affordable for small
businesses at all. I'm betting right now this will not be a problem (I
stress that this easy and low cost access web hosting is an assumption on my
part).
>> There's no question that some companies will want their own web
>> server, but the vast majority of my clients and customers simply
>> don't want bothered with setting up a web server to run that
>> software.
>
> ????
>
> I don't know what issue you're addressing here.
>
Simply that most businesses don't want go through the expense and time is
setting up their own web servers. On the other hand, if they don't have a
server, then what software standard am I going to write my web solutions to?
So, this is where the cloud based operating systems come into play. We now
just write to that particular cloud based os, and we have a packaged
solution that we can sell to customers. So, our install + development model
is very much like what we have for the desktop.
Most web based applications take a LOT of setup work by the customer to
make that software run on their web servers. These cloud system means our
customers don't have to spend huge amounts of money and time to setup our
software.
Right now we write to a system called windows. We need the same for the web.
Many of my customers have hosted web systems, but I can't just send them a
web based application that will run on their systems. Cloud based systems
opens up this opportunity for a smaller developers like me to package my
applications.
I am quite excited about what I see. I see Cloud computing opening up a lot
of opportunity for smaller developers like me.
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>
> Some people don't maintain their cars well, and I've seen some
> businesses with some pretty crappie delivery trucks. Others have
> beautiful drop dead gorgeous delivery trucks. Fact is some
> businesses don't always do the best thing. However for a lot of
> businesses, cheaper and less cost = simply better this happens all
> too often..
I am not convinced that it will be cheaper. What you might save in
IT infrastructure you will spend in buying a higher level of
connectivity (i.e., you'll need multihomed Internet access with more
than one provider). And I'm also not convinced you'll get rid of any
significant component of your IT costs, since you'll want you'll
need someplace for the offline storage and for backups of your cloud
data (you don't seriously think you'd use the cloud to backup cloud
data?).
I recall back in my early Access days I had a client who insisted
they wanted to get rid of all the paperwork. I nodded my head and
ignored it, because I knew perfectly well that there was no possible
way to get rid of all the paper, nor was it desirable to do so.
Paper is a really great technology and solves a whole lot of
problems, even if it can be hard to manage.
Our current IT infrastructure has many good things that come along
with the annoyances and costs. But anyone who thinks that could
computing is going to actually save money in the long run is
foolish, in my opinion. It may make it possible for us to do a
better job of maintenance, or to be better able to implement
upgrades and such, but I doubt that it's going to be cheaper -- it
will just move the costs somewhere else.
This is, in my opinion, the same thing that computerization had done
for us. It's not so much that we can do more work, but that we can
do the work better and with lots of features included that were
inconceivable or impossible before computerization. I would expect
the benefit of the could to be similar -- no actual decrease in IT
budgets, but in the long run, a nimbler, more responsive IT
infrastructure (assuming that the people implementing it are not
idiots, of course).
>>> twitter and social networking is not a fundamental engineering
>>> problem that our computer industry is attempting to solve by
>>> adopting these new technologies. perhaps some of the social
>>> networking saw the result of adoption this new technology, but
>>> at the end of the day twitter is not an engineering solution for
>>> access or software developers.
>>
>> In the period 1990-95 or so, it was all about thin clients, which
>> was a solution to "a fundamental engineering problem" for the
>> computer industry. It never happened (or, at least, only in a
>> limited fashion, and not at all in the way it was originally
>> conceived of -- we run thin client applications on fat client
>> hardware, but the thin client hardware never really
>> materialized).
>
> Actually there's quite a few vendors that created thin clients.
Yes, but they didn't replace fat clients, which was the forecast
that everybody was making back then (not just the people with a
vested interest). And that's my point here -- cloud computing is
going to be adopted in certain places but is not going to completely
replace local computing.
> However, if
> you want to know why thin client computing such as terminal
> services was never going to be mainstream or a huge success, all
> you had to do was ask me 7 years ago, and read the following
> article of mine:
>
> Why bother with .net when you have Thin Client?
> http://www.members.shaw.ca/AlbertKallal/Articles/ThinClientsand.net
> .html
>
> (you don't have to go and read it).
>
> To make a long story short, I explain in that article 7 years ago
> why.net's going to be a better choice than thin client. The reason
> was simple and that is that terminal services did not solve some
> of the fundamental problems that we developers needed to be solved
> when we develop software. so, again, as I said, if you ask the
> right questions, then you can tell if something being pushed is
> going to be a success or not...
I never believed the think client hype, Albert, and my disbelief
long predates your 7-year-old article. It was obvious that the hype
was overblown, and that the thin client proponents underestimated
the benefits of fat clients.
I see exactly the same thing happening with the promoters of cloud
computing. I never said thin clients wouldn't be useful in certain
applications, just like I'm not disputing that cloud computing will
be a big help for certain applications. It's the claim of ubiquity
in both cases that I'm disputing.
Somewhere in between ubiquitous cloud computing and no cloud
computing is where we'll end up. My bet is that there will be a mix
of computing platforms in the cloud and local and that duties will
be transparently shared between them. The user won't care which CPU
is handling the task, nor whether the data is being pulled from a
hard drive in the local server closet or from a RAID array in a data
center thousands of miles away.
The question is what the balance will be.
To me, far more important than the cloud is the issue of transparent
load sharing. That is, the aspect of the cloud that is most
important is that the system is virtualized at the highest level and
you don't know or care where the actual computing is being done.
That could be a benefit even with nothing hosted on the Internet --
it would be the ultimate load balancing system.
And that's not here yet, so far as I'm aware.
>> But that seems to be too small-scale for you. You're not happy
>> with that, you seem to need to push the bigger picture, and I
>> think you're overclaiming in that regard, and that could
>> discredit your closely focussed comments about A2010/Sharepoint.
>
> Actually, my point was I think for the smallest of businesses we
> now can move some line of business things (that should be moved by
> the way!) to the web. We are going to benefit as much if not more
> then the larger businesses that already has invested in these huge
> IT infrastructures to provide those web systems and line of
> business applications for their customers.
>
> With cloud computing, we will now be able to develop and offer web
> solutions to our customers at an affordable cost - both hosting
> wise, and both development cost wise. If we write to that
> particular cloud operating system, then things like database
> servers, even payment processing and email marketing systems will
> simply be components and services that we can include into our
> applications (just like we include things like word and outlook
> now into our desktop applications).
I see that as a problem. There's a reason for custom software
development and that's because the available choices don't fit well
enough the perceived needs of the client. If these hosted
application components are upgraded, what happens to your
customizations? What if the upgraded version has bugs?
Right now I'm working on a client's website that has to be rewritten
to run on PHP5. There is nothing obviously wrong with the code
(i.e., it's not doing any of the things that were legal (and
inadvisable) in PHP4 but illegal in PHP5), but it doesn't run. In
regard to the features of PHP used in this website, almost none of
them were touched in the rewrite of PHP5. But it doesn't run on
PHP5, nonetheless. I'm not deep enough into it to know what the
exact issues are, but the point is that you can't just independently
update the platform on which your customized app runs without
carefully checking that it works properly.
I don't for a minute believe that there won't need to be
customization for line-of-business applications, and those are the
ones that are most crucial in terms of reliability.
I just don't think it's going to happen the way you suggest.