Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms
Bob Alston
possible to store access 2010 data on Sharepoint 2010 but still run
the Access client in windows much as a "normal" access client,
accessing the data on Sharepoint 2010.
"Well, the rich VBA application can sit on your desktop, but the data
sits on
SharePoint. You can also have the application sit on SharePoint and a
copy
gets pulled down sure local machine when you click on and on the
SharePoint
site, you'll need access installed for this to occur. So, in this case
we
much talking about a 100% VBA application . "
http://groups.google.ca/group/comp.databases.ms-access/msg/9cb8348d8fb6dfbd
OK I am very interested in this approach as it allows maximum use of
existing Access coding investment with the ability to share an app
amount users physically separated. Previously you had to limit Access
users to a LAN, or use terminal server or maybe even replication via
the internet. This seems much slicker.
Again my interest is data on sharepoint 2010 and use normal windows/
Access clients on each user's PC. I am not trying to take about the
new web forms and reports which run in a browser.
My question, is what do you have to do, if anything special, to have
the application you published be available on the Sharepoint 2010
workspace so it can be pulled down to the desktop and run there? I
just finished successfully publishing my test app to Sharepoint 2010
that I installed on my local PC. When I go to the workspace via the
IE interface, I see all the database components - tables, queries,
forms, reports, etc. What I do not see is any "overall" application
that can be downloaded and run. What am I missing?
Thanks
Bob Alston
Albert D. Kallal
In other words, the data can reside on a backend accDB file sitting
on a server, and the front end pulled down from SharePoint
(but, this case, this means you suing a spit system, and that is NOT
appropriate for wireless or a wan).
Watch the following video. They go through all 3 possible:
1) 100% web
2) just sending the tables and data, but still rich front end (your case)
3) sending up a split database, and CONTINUING to use the standard back end,
but
the whole thing comes down from SharePoint...
Managing Access Databases with SharePoint
http://blogs.msdn.com/access/archive/2009/12/02/the-access-show-managing-access-databases-with-sharepoint.aspx
Remember, we could upsize + send the tables to SharePoint in 2007, but the
problem was performance, and also that we did not have any cascade
relationships ability. So, for 2010, we have much better performance, and we
have the ability for share to manage relationships. However, keep in mind
the relationships and tables STILL MUST follow the restrictions for
SharePoint lists (no compound keys, keep the PK as a autonumber id).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com
Albert D. Kallal
Bob Alston
it was not what I expected. It was under the link to edit the app. I
opted to download the file named <sharepoint workspace>.accdw
Yes, that extension is correct. It seems to open up and be run by the
Access 2010 client.
Bob
Bob Alston
> Albert D. Kallal wrote:
>> Managing Access Databases with SharePoint
>> http://blogs.msdn.com/access/archive/2009/12/02/the-access-show-managing-access-databases-with-sharepoint.aspx
>>
>>
>>
> I was able to find the app available for downloading on Sharepoint, but
> it was not what I expected. It was under the link to edit the app. I
> opted to download the file named <sharepoint workspace>.accdw
> Yes, that extension is correct. It seems to open up and be run by the
> Access 2010 client.
>
> Bob
once an access database is published - data and other objects - to
Sharepoint 2010 - can you talk more about how any authorized user can
access the Access windows client and download it and run it on the
desktop and still be using or at least updating/syncing with the data on
Sharepoint. From what I have tried, it appears that the Access front
end becomes named <sharepointworkspace>.accdw
Also need to identify how to restrict a user who the designer is going
to allow to download the front end app, to access it and only it and
download it?
Also can you speak to whether or not the downloaded db has a local cache
of data that is manipulated directly and then automatically synced to
sharepoint?
Also, can a laptop user, use the downloaded front end app,
<sharepointworkspace>.accdw, when disconnected to sharepoint? When
reconnected will it be auto resynced?
Bob
Albert D. Kallal
news:1JHSm.38493$cX4....@newsfe10.iad...
> It was under the link to edit the app. I opted to download the file named
> <sharepoint workspace>.accdw
> Yes, that extension is correct. It seems to open up and be run by the
> Access 2010 client.
>
Yes. Remember, you can copy a pdf, a picture, word, excel or whatever to
SharePoint. You can also copy a file like ms-access accDB file to the
server.
However, to establish "linked" copy of ms-access in which changes are auto
synced up/down, you don't just up-load the file, you must publish the file.
And, keep in mind since you have NO web parts, then there will be no web
forms etc. on the SharePoint site. However, you STILL need to do this to
setup the replication and auto upload (and auto download) of changes you
make.
Remember, you have to two options to sending up your local tables and
linking them (they both are covered in that video).
So, you can upsize the data to SharePoint. However, that will NOT give you
the auto-updated front ends. You have to publish your application (but,
since there no web forms, then you not see/have a web application). however,
it is act of publishing that sets up the "replication" of your changes. So,
now that you have the client downloaded, and you modify one form (say, edit
some VBA in the form). when you sync your changes, then everyone else who
downloaded a copy, when then launch the client application, then they will
be informed there is changes to sync from the SharePoint system. when they
sync, then your forms + code you changed will be sent down the write to
their desktop.
So, upsizing your tables is STILL different process then that publishing the
database.
So, if you just want to send up your tables and link them to SharePoint, use
the external data tab. It will pump up all of your tables, and then setup
links (this also the SAME process you have in access 2007 and SharePoint).
As mentioned, this very much the same as using the upsizing tools (in that
same tab on the ribbon) to up-size to sql server. when you do this, all that
occurs here is moving of the tables up to SharePoint (or sql server) and
then links are crated.
However, to have changes you make to reports/forms/VBA code in a module,
then you have to use the publishing option (available only in access 2010).
So, publishing an application without any web parts is the same as upsizing
+ setting up the part that will auto update the front ends that everyone
downloaded...
David W. Fenton
news:qoHSm.49392$ky1....@newsfe14.iad:
> 1) 100% web
> 2) just sending the tables and data, but still rich front end
> (your case) 3) sending up a split database, and CONTINUING to use
> the standard back end, but
> the whole thing comes down from SharePoint...
Is there the option to have your back end in SQL Server and use
Sharepoint for nothing but distributing your app? I don't think the
engine-level data integrity capabilities of Sharepoint 2010 are yet
sufficient for a real application (the lack of compound indexes is a
deal-breaker for me), so I'd be wary of moving the data storage to
Sharepoint lists.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
David W. Fenton
> once an access database is published - data and other objects - to
> Sharepoint 2010 - can you talk more about how any authorized user
> can access the Access windows client and download it and run it on
> the desktop and still be using or at least updating/syncing with
> the data on Sharepoint. From what I have tried, it appears that
> the Access front end becomes named <sharepointworkspace>.accdw
I also wonder about controlling distribution. That is, the
programmer makes changes to the source ACCDB app and I'd assume that
once the changes are synched with the Sharepoint server version,
everybody gets the updates. That means the programmer has to be
careful to be sure not to synch before everything has been tested.
A usual scenario using Tony's FE Updater would be:
1. developer copy of front end on developer's PC.
2. beta copy on server, updated when the developer wants to push out
a new update to the beta testers.
3. the users who are beta testers have a shortcut that points to the
updater script for the beta version, and will get the beta copy if
the click that shortcut.
4. production version on server, updated when the developer has
determined that beta version has passed testing successfully.
5. all users have a shortcut that runs the updater script to pull
down this copy.
I'm having a hard time, based on what little I know about the
publishing/synching capabilities of Sharepoing, imagining how
Sharepoint could work with this scenario. I've heard nothing about
controlling this kind of thing with the built-in synchronization.
David W. Fenton
> However, to have changes you make to reports/forms/VBA code in a
> module, then you have to use the publishing option (available only
> in access 2010). So, publishing an application without any web
> parts is the same as upsizing + setting up the part that will auto
> update the front ends that everyone downloaded...
Albert, can you look at my other post, replying to Bob, asking about
version control issues with synchronizing a published app? It sounds
like an all-or-nothing situation, and that the developer will need
to be very careful to not synchronize prematurely. This makes it
hard to maintain beta versions, though I guess you could beta test
by manually giving the users the beta front end (or use Tony's
updater), but that means you've made it easier to accidentally
publish the beta version (by synching too soon).
Is it possible to roll back changes that have been synched without
editing out the changes?
Albert D. Kallal
news:Xns9CD9A9BF68F92f9...@74.209.136.99...
>
> Albert, can you look at my other post, replying to Bob, asking about
> version control issues with synchronizing a published app? It sounds
> like an all-or-nothing situation, and that the developer will need
> to be very careful to not synchronize prematurely.
Well, if you save a word document, or the act of saving a form, or
hitting send on your email, is this any different?
I mean, one has to assume one does not want to sync your forms/code
etc. until you ready?. However, I not really sure I understand how this
is related to un-doing changes? As a developer you ALREADY had made the
changes regardless if you synced or not. In other words, the act of
making changes is somewhat separate from hitting sync. if you made
changes, and not synced, then I don't see how this is any different
from developing in ms-access now?
I mean, if you don't want to sync, then don't sync ??? However,
if you made changes you don't want, then syncing not going to fix
or change the fact that you made changes you don't want...
>
> Is it possible to roll back changes that have been synched without
> editing out the changes?
>
Hum, I doubt this is much different then hitting save for a document, or
saving a form in ms-access. We really never had the ability roll back out
AFTER we saved a form or code. The only exception if we were using source
code
control, then yes you could roll your changes back to a previous version (in
fact you can roll back to multiple different versions with source code
control).
It possible I not understanding the question here, but one simply to revert
back a form
or some code that you changed, then do what we always done: go to the backup
copy and
cut+paste the code, or if it whole form we messed up, delete the form, and
import the
form from the backup copy. I mean, sure, if you hit sync already, then
import the form,
and then whack sync to send out what the original form was.
I assume you always make a backup copy before you start working. I don't see
anything
here that would suggest you stop making backups of your work.
We don't have version controls now, and if you work all day long, and
then mess up one form, you not going to the backup and going to copy
over your work. In most cases you are key just recovering the one bit
of code or form or report or query from the backup.
it is possible that your process of reverting back to some previous code is
diffent then how I work, so I suppose your mileage would vary on this
issue..
I suppose at the end of the day there might be some new issues to deal with.
Such as perhaps when you import a form from the backup copy the timestamp or
some such is not updated. Perhaps one might have to "dirty" the form, but I
am not aware of this issue as of yet. It certainly something I just don't
have experience with at this point in time, but my current understanding of
this does not see a particular problem that any differnt then what an
average developer ALWAYS had to deal with..
There are some other big questions and big issues I see for syncing out
changes, but that of revering back to a form or some code in a backup copy
is not one those concerns or issues I see as a problem.
Albert D. Kallal
>
> I'm having a hard time, based on what little I know about the
> publishing/synching capabilities of Sharepoing, imagining how
> Sharepoint could work with this scenario. I've heard nothing about
> controlling this kind of thing with the built-in synchronization.
>
I think the decision here is will one work on a copy that is attached to the
live data or not. If one is not going to work on the live copy that being
synced, then you don't have a problem of syncing by accident. But then again
one would not really be using the sync ability to keep this updated anyway.
If you have a separate dev system, then you would have to re-link tables to
production data. You then take the dev copy and overwrite the production
copy. We will just have to get more experience with this issue as time
unfolds.
You can see my other post here when I mention versioning. As I mention, I
don't think the issue of going back to old forms or code is an new issue.
Ensuing that a 100% new dev copy gets sent out may need some extra steps to
ensure this works.
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:qoHSm.49392$ky1....@newsfe14.iad:
>
>> 1) 100% web
>> 2) just sending the tables and data, but still rich front end
>> (your case) 3) sending up a split database, and CONTINUING to use
>> the standard back end, but
>> the whole thing comes down from SharePoint...
>
> Is there the option to have your back end in SQL Server and use
> Sharepoint for nothing but distributing your app? I don't think the
> engine-level data integrity capabilities of Sharepoint 2010 are yet
> sufficient for a real application (the lack of compound indexes is a
> deal-breaker for me), so I'd be wary of moving the data storage to
> Sharepoint lists.
>
> --
Yes, you can have linked tables to standard ms-access back end, or even sql
server. You not have web parts, but what you propose is legal. So, yes, the
above even works with linked tables to a standard access backend. The back
end on the server will not be pushed down by SharePoint and users would have
to have legal file permissions to that back end path, but yes, the FE with
linked tables to sql server or an access back end will work for this setup.
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>
>>
>> I'm having a hard time, based on what little I know about the
>> publishing/synching capabilities of Sharepoing, imagining how
>> Sharepoint could work with this scenario. I've heard nothing
>> about controlling this kind of thing with the built-in
>> synchronization.
>>
>
> I think the decision here is will one work on a copy that is
> attached to the live data or not. If one is not going to work on
> the live copy that being synced, then you don't have a problem of
> syncing by accident. But then again one would not really be using
> the sync ability to keep this updated anyway. If you have a
> separate dev system, then you would have to re-link tables to
> production data. You then take the dev copy and overwrite the
> production copy. We will just have to get more experience with
> this issue as time unfolds.
The paragraph above seems to apply to data. I wasn't talking about
data, only the front end.
> You can see my other post here when I mention versioning. As I
> mention, I don't think the issue of going back to old forms or
> code is an new issue. Ensuing that a 100% new dev copy gets sent
> out may need some extra steps to ensure this works.
The paragraph above is uninformative to me -- I don't understand
anything it says.
If you've got a front end that you're distributing through
Sharepoint, don't users get the updates when you synch front-end
changes to the server? If so, how do you control that?
If not, then I seem to have really misunderstood something somewhere
along the line.
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9CD9A9BF68F92f9...@74.209.136.99...
>> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
>> news:uAAQFBkd...@TK2MSFTNGP02.phx.gbl:
>
>>
>> Albert, can you look at my other post, replying to Bob, asking
>> about version control issues with synchronizing a published app?
>> It sounds like an all-or-nothing situation, and that the
>> developer will need to be very careful to not synchronize
>> prematurely.
>
> Well, if you save a word document, or the act of saving a form, or
> hitting send on your email, is this any different?
Front-end development is an order of magnitude more complicated.
That's why version control systems exist for software but not for MS
Word documents.
> I mean, one has to assume one does not want to sync your
> forms/code etc. until you ready?. However, I not really sure I
> understand how this is related to un-doing changes? As a developer
> you ALREADY had made the changes regardless if you synced or not.
> In other words, the act of making changes is somewhat separate
> from hitting sync. if you made changes, and not synced, then I
> don't see how this is any different from developing in ms-access
> now?
I had to roll back a beta version today. It was easy -- the user who
had the test version just reverted to the version before the one I'd
given him on Friday.
I didn't revert the development copy to the previous code.
I can't see how the Sharepoint distribution system could handle
that, at least not based on my understanding of how it works.
And none of your comments address the beta vs. production issue.
> I mean, if you don't want to sync, then don't sync ??? However,
> if you made changes you don't want, then syncing not going to fix
> or change the fact that you made changes you don't want...
Are you being purposefully obtuse here? It's really easy to
prematurely publish. I've done it numerous times and had to quickly
roll out a replacement. With file-based distribution, I just revert
to the previous file version. With Sharepoint distribution, I don't
know how this would work. Could you keep a copy of the old and synch
it? Would that destroy the changes synched from the later version?
>> Is it possible to roll back changes that have been synched
>> without editing out the changes?
>
> Hum, I doubt this is much different then hitting save for a
> document, or saving a form in ms-access. We really never had the
> ability roll back out AFTER we saved a form or code.
But we have the ability to save versions of our front end as
individual files and rollback to those.
> The only exception if we were using source
> code
> control, then yes you could roll your changes back to a previous
> version (in fact you can roll back to multiple different versions
> with source code control).
I think you're trying really hard to ignore what seems to me to be
something that is flawed and is going to make the feature pretty
much useless for ongoing development projects.
[]
> There are some other big questions and big issues I see for
> syncing out changes, but that of revering back to a form or some
> code in a backup copy is not one those concerns or issues I see as
> a problem.
You haven't even touched on the beta vs. production issue.
Based on that, I'd guess that Tony's front-end updater is not going
to be obsoleted by Sharepoint distribution.
Albert D. Kallal
>
> I had to roll back a beta version today. It was easy -- the user who
> had the test version just reverted to the version before the one I'd
> given him on Friday.
>
> I didn't revert the development copy to the previous code.
>
Right, and to do that you kept a copy of that version ...right?
>
> I can't see how the Sharepoint distribution system could handle
> that, at least not based on my understanding of how it works.
>
> And none of your comments address the beta vs. production issue.
>
I had thought I did??? I said if you working on your dev system, then
before deployment you have to re-link to production data. You then
overwrite the existing production copy on the server. However,
it would be quite funny if you were not to make a copy of that
before you do this? I also stated and brought up there might
be some timestamp issues, but we have to learn this as we
go along.
So, I am assuming one would do what they ALWAYS done and work
on a copy on their dev system. (both data and FE). I also
assuming that before deployment we going to save a copy of
that FE? You could not possibility be standing here as an
serious developer and telling me that this needs to be told
to everyone?
Again I don't really see the version issue
as being any different at all here? How is keeping a copy of
the version from your dev system before you deploy going to
be any different now?
Surely you jest that it needs pointing out that developers don't know to
save a copy of the current version before they deploy?
I stated in my other post that their might be some different issues in terms
of a timestamp issue that we figure out over time with more experience.
Other then this timestamp issue I pointed out, why would someone not keep a
copy of the particular production version before they deploy?
> Are you being purposefully obtuse here? It's really easy to
> prematurely publish.
No, I am not. But I think if we have to stand here and tell people that they
need to make a copy of their software before they deploy then we really
sinking to new lows in this group are we not?
> Could you keep a copy of the old and synch
> it? Would that destroy the changes synched from the later version?
>
I stated that I don't see why we can't in that other post. I don't see why
we can't over write the copy on the server.
>
> But we have the ability to save versions of our front end as
> individual files and rollback to those.
>
Right, and why would you not continue that practice? I just don't see this
problem?
I not convinced that just using SharePoint to distribute a front end is the
best use of SharePoint. However, if it is available, it would facilitate new
users of the application not needing some type of install or setup like
Tony's updater system.
Keep in mind while you can use linked tables to a BE, or linked tables to
SQL server, you can NOT have local tables in the front end when you do this.
I just assumed that every developer on the planet would keep a copy and that
part never needed pointing out or even crossed mind.
So, yes, I did point out the ONE issue of timestamps, and the possibility
some issues arising out of timestamps. However if it helps, yes, before you
decide to overwrite that copy sitting on SharePoint, you want to make a copy
to save that version in case you need to revert back to it...
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>
>> I had to roll back a beta version today. It was easy -- the user
>> who had the test version just reverted to the version before the
>> one I'd given him on Friday.
>>
>> I didn't revert the development copy to the previous code.
>
> Right, and to do that you kept a copy of that version ...right?
Yes, but a WHOLE FILE. I didn't copy anything into the new file, but
simply distributed the previous version in place of the current
version until current development version was ready for release (to
the beta tester, as a matter of fact).
Can you synch your development copy and then revert to a previous
version of the file and synch and have it undo the 1st of those two
synchs?
>> I can't see how the Sharepoint distribution system could handle
>> that, at least not based on my understanding of how it works.
>>
>> And none of your comments address the beta vs. production issue.
>
> I had thought I did??? I said if you working on your dev system,
> then before deployment you have to re-link to production data.
The issue has NOTHING to do with production data, or with any kind
of data. My question is all about front-end distribution -- I am not
contemplating Sharepoint for data at all at this point.
> You then
> overwrite the existing production copy on the server. However,
> it would be quite funny if you were not to make a copy of that
> before you do this? I also stated and brought up there might
> be some timestamp issues, but we have to learn this as we
> go along.
First off, my clients don't have different servers. Most of them
don't have *any* servers, so talk of a "production server" is simply
laughable.
I outlined a common system, using Tony's front-end updater, where
beta testers have two shortcuts, one to launch the latest beta, one
to launch the production database. You haven't addressed how to map
that system onto Sharepoint distribution of a front end.
> So, I am assuming one would do what they ALWAYS done and work
> on a copy on their dev system. (both data and FE). I also
> assuming that before deployment we going to save a copy of
> that FE? You could not possibility be standing here as an
> serious developer and telling me that this needs to be told
> to everyone?
You're assuming a lot of things and ignoring my actual description
of the architecture in question.
> Again I don't really see the version issue
> as being any different at all here? How is keeping a copy of
> the version from your dev system before you deploy going to
> be any different now?
I'm not talking about keeping the development versions. I'm talking
about how users get the changes. How does one manage with Sharepoint
updating of a front end to maintain the difference between your beta
front end and your production front end? Is it as simply as keeping
the development copy in one folder on the developer's machine,
synching that to the server, and then moving it to a different
folder on the development machine when it's ready for production
distribution and then synching that with Sharepoint? Does Sharepoint
see it as a different source database because it's in a different
location? If so, that would work, I guess.
But I'm guessing -- this is what I'm asking you about, and you're
mixing in a bunch of imaginary stuff out of your own head about
production servers, instead of starting from the scenario I
described.
> Surely you jest that it needs pointing out that developers don't
> know to save a copy of the current version before they deploy?
>
> I stated in my other post that their might be some different
> issues in terms of a timestamp issue that we figure out over time
> with more experience.
>
> Other then this timestamp issue I pointed out, why would someone
> not keep a copy of the particular production version before they
> deploy?
Perhaps you're too close to understand what I don't understand.
Of course I save copies of each development stage. Indeed, I rename
my front end as I develop with the expected release date. The app
that got reverted last week now has a development copy named
lionheartDB20091210.mdb, because it's intended to be released on
Thursday (it may or may not be). When it's ready for testing, I'll
strip the dates from the filename and send it to my tester who will
place it in his testing folder and test it (they use live data, as
the point of the testing is to figure out if it is stable enough for
daily use). When it's determined that its ready for production use,
it then gets copied to the folder from which the production front
end is distributed (it's actually a manual process, but that's
immaterial here, as the questions are not about the mechanism, but
about managing the process).
I am still working on lionheartDB20091210.mdb until the beta goes
into production, at which time I copy it to the archive and rename
the development copy to the next expected release date.
Now, in a Sharepoint front-end distribution scenario, what I imagine
is that once each user has a copy of the front end, they just choose
to synch with the Sharepoint server whenever they are informed that
there are updates to the front end.
In that scenario (assuming it's correct), how would I keep the
regular users from getting the beta version, other than telling them
not to synch?
How does Access know which Sharepoint-distributed front end to synch
with (I don't know what the appropriate terminology is for the
Sharepoint feature of distributing and synching a front end)? How
could I copy the beta version to production and have Access know
that it now needs to synch with the Sharepoint production version
instead of the Sharepoint beta version?
>> Are you being purposefully obtuse here? It's really easy to
>> prematurely publish.
>
> No, I am not. But I think if we have to stand here and tell people
> that they need to make a copy of their software before they deploy
> then we really sinking to new lows in this group are we not?
It's not a matter of keeping a backup, but a matter of changes going
out prematurely to the users. It's not clear to me from your answers
if in that scenario I can revert by simply copying the backup file
over top of the new file and then resynching (of course, I wouldn't
actually copy over top of it, just rename, copy to the old file
name, resynch, and then go back to the prematurely-published
version).
>> Could you keep a copy of the old and synch
>> it? Would that destroy the changes synched from the later
>> version?
>
> I stated that I don't see why we can't in that other post. I don't
> see why we can't over write the copy on the server.
But does it actually work? I'm not in a position to test, nor are
many other people.
>> But we have the ability to save versions of our front end as
>> individual files and rollback to those.
>
> Right, and why would you not continue that practice? I just don't
> see this problem?
>
> I not convinced that just using SharePoint to distribute a front
> end is the best use of SharePoint. However, if it is available, it
> would facilitate new users of the application not needing some
> type of install or setup like Tony's updater system.
Your answers have almost convinced me that Sharepoint won't be able
to replace Tony's updater (or any similar system). You say "I don't
see why we can't" in regard to the question of copying an older
version over top of a newer and resynching, but that's not good
enough. "Can't see why not" is not sufficient -- I would need to
know whether it works or not.
I can't see how it would, to be honest, but my perspective on that
is with Jet replication, where you can't undo a synch, except by
actually editing the data to reflect the previous state.
> Keep in mind while you can use linked tables to a BE, or linked
> tables to SQL server, you can NOT have local tables in the front
> end when you do this.
>
> I just assumed that every developer on the planet would keep a
> copy and that part never needed pointing out or even crossed mind.
You're completely missing the point, Albert.
> So, yes, I did point out the ONE issue of timestamps, and the
> possibility some issues arising out of timestamps. However if it
> helps, yes, before you decide to overwrite that copy sitting on
> SharePoint, you want to make a copy to save that version in case
> you need to revert back to it...
But *can* you revert back to it? I wasn't suggesting that one didn't
keep copies. I was only asking if the premature synch is reversible.
You say you "don't see why you can't," which is not an answer at
all.
Daniel A. Galant
I'm completely lost here as to what you are trying to do. A SharePoint Front
End server is simply the access point that a user connects to to then get at
whatever data you are trying to make available. The front ends don't sync to
anything, they pull data from a backend SQL server. How that data gets into
SQL can be a number of ways. SharePoint can also be used to present data
from other sources as well as SQL through web parts, connections etc. If I
lose a SharePoint front end server from my farm, it's not a real big deal,
as I can simply create a new one and it will pull the data it requires from
the SQL server's configuration database for the farm and start working.
(There is a little more to it than that, such as any customizations, host
headers that may also need to be considered, but effectively it is just a
matter of adding a server to the farm).
As for moving data from dev to production, this is often done through the
content management function of SharePoint whereby you link a site in the dev
environment to one in the production and then publish data from one to the
other. This is a one way operation.
--
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns9CDBA44DF911Ff9...@74.209.136.90...
Bob Alston
> Ok, I'll admit that I've been trying to follow a bit of this discussion
> and I'm completely lost here as to what you are trying to do. A
> SharePoint Front End server is simply the access point that a user
> connects to to then get at whatever data you are trying to make
> available. The front ends don't sync to anything, they pull data from a
> backend SQL server. How that data gets into SQL can be a number of ways.
> SharePoint can also be used to present data from other sources as well
> as SQL through web parts, connections etc. If I lose a SharePoint front
> end server from my farm, it's not a real big deal, as I can simply
> create a new one and it will pull the data it requires from the SQL
> server's configuration database for the farm and start working. (There
> is a little more to it than that, such as any customizations, host
> headers that may also need to be considered, but effectively it is just
> a matter of adding a server to the farm).
>
> As for moving data from dev to production, this is often done through
> the content management function of SharePoint whereby you link a site in
> the dev environment to one in the production and then publish data from
> one to the other. This is a one way operation.
>
was and is to pursue using Access 2010 as a rich client front end to
data that is stored/hosted in Sharepoint. While it is possible to use
SQL server and other back ends, Microsoft is providing software to
migrate the data from Access to Sharepoint. Doing this allows an Access
app to be shared by geographically distributed Access users. Normally,
an access database is limited to LAN based sharing.
Also interesting in this approach is that the Access front end, once
synced with Sharepoint, actually runs using a local cache of the data.
It then syncs/updates the data in Sharepoint in the background.
These videos - posted previously - have a pretty good explanation.
http://channel9.msdn.com/learn/courses/Office2010/OfficeServicesUnit/DevelopingWithAccessServices/
HTH
bob
Albert D. Kallal
news:OtUQ35Fe...@TK2MSFTNGP05.phx.gbl...
> The front ends don't sync to anything, they pull data from a backend SQL
> server.
Actually, with SharePoint, they now do.....
Right, but we not talking about the data here, we talking about syncing
changes to the applications.
Individual parts of the application (forms, reports, code) after being
modified can thus be synced to the copy sitting on SharePoint. This is NOT
the whole application being changed, but ONLY the parts that have been
worked on.
The above is based on the new features in ms-access in which you can "web"
publish an access application to SharePoint. So, after you web published
then if you modify a SINGLE form, or some code on the CLIENT side and then
hit the sync button, those changes are then synced from the desktop client
to the copy of the application sitting on the server. Any other user that
decides to open the client application via SharePoint (thus does not yet
have a copy of the application on their desktop) will then get a copy of the
application downloaded to their desktop. And, after that occurs, again I can
modify ONE form, and ONLY the one form is synced, NOT A WHOLE copy of the
application. So, any one who has one of these copies on their desktop will
receive NEW updates if a form is modified next time they launch the
application.
Now, the above is generally assume to be a web based application in
ms-access. (just to get you up to speed, access 2010 allows 100% browser
based (web) applications to be built using SharePoint 2010).
However, since ms-access allows a mix of both VBA forms (non web), and also
100% web forms, the above automatic "replication" or "deployment" system CAN
ALSO be used for 100% non web based applications. (but, to be clear, you
actually are talking about a web based application with VBA forms in it).
You can also upsize, or setup linked tables to SharePoint lists in
ms-access, but that's not what we are talking about.
So, that "published" application (the act of publishing has significant
meaning here by the way) thus might not have any web components, and might
not even have its data on SharePoint. However, that app can still have rich
VBA forms that are based on tables linked to SharePoint, SQL server, or even
a back end access on a file share.
So, this discussion is talking about syncing the application parts, NOT the
data part. The question being asked is while I am developing an application,
what happens if I accidently sync out my ONE OF my VBA forms that was
working on. If I DID NOT want to send out this form then how can I revert
the application back to the previous version of the application..... That is
our context of this discussion...
Daniel A. Galant
What is happening here is that Access Services (a feature of 2010, so not
currently available in this manner in SharePoint 2007) is taking the data of
your Access database and converting it to SharePoint lists and forms, doing
the behind the scenes work so you don't have to. The data is still stored in
the backend SQL server, stored in the content database of the site
collection where you publish your Access application. If your user then
accesses that 'application' using Access, it will download the data and
convert it back into the relevant Access database using a local copy (as you
mention) and then push any changes back up into SharePoint. What this does
is allows users to access the information either using Access or a web
browser, since SharePoint is now handling the data management.
All the normal SharePoint rules will still apply. Lists, items, libraries
etc. The Access application simply becomes a set of these in a SharePoint
site. If you publish an early or premature version of your application,
SharePoint will create the lists, forms etc, for this app. Not having played
with any of this yet, (Access is certainly not my forte) while there is
supposed to be two way synchronization, I don't know that re-publishing an
earlier version of the app will delete any lists or forms that would have
been added by your premature push of a newer version of the application.
I hope this is making some sense within the context of the thread.
--
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"Bob Alston" <bobal...@yahoo.com> wrote in message
news:eCBTm.45381$ZF3....@newsfe13.iad...
Daniel A. Galant
--
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in message
news:DhITm.85021$Xf2....@newsfe12.iad...
> "Daniel A. Galant" <daniel...@mindsharp.com> wrote in message
> news:OtUQ35Fe...@TK2MSFTNGP05.phx.gbl...
>
>> The front ends don't sync to anything, they pull data from a backend SQL
>> server.
>
> Actually, with SharePoint, they now do.....
>
> Right, but we not talking about the data here, we talking about syncing
> changes to the applications.
>
> Individual parts of the application (forms, reports, code) after being
> modified can thus be synced to the copy sitting on SharePoint. This is NOT
> the whole application being changed, but ONLY the parts that have been
> worked on.
>
This is still data that is stored inside of SQL. Just as if I added a new
column to a list or library. No argument.
> The above is based on the new features in ms-access in which you can "web"
> publish an access application to SharePoint. So, after you web published
> then if you modify a SINGLE form, or some code on the CLIENT side and then
> hit the sync button, those changes are then synced from the desktop client
> to the copy of the application sitting on the server. Any other user that
> decides to open the client application via SharePoint (thus does not yet
> have a copy of the application on their desktop) will then get a copy of
> the application downloaded to their desktop. And, after that occurs, again
> I can modify ONE form, and ONLY the one form is synced, NOT A WHOLE copy
> of the application. So, any one who has one of these copies on their
> desktop will receive NEW updates if a form is modified next time they
> launch the application.
>
> Now, the above is generally assume to be a web based application in
> ms-access. (just to get you up to speed, access 2010 allows 100% browser
> based (web) applications to be built using SharePoint 2010).
>
> However, since ms-access allows a mix of both VBA forms (non web), and
> also 100% web forms, the above automatic "replication" or "deployment"
> system CAN ALSO be used for 100% non web based applications. (but, to be
> clear, you actually are talking about a web based application with VBA
> forms in it). You can also upsize, or setup linked tables to SharePoint
> lists in ms-access, but that's not what we are talking about.
>
You can't use VBA when creating an Access database that you are going to
push up to SharePoint. VBA, Action Queries and traditional Access macros are
not supported by Access Services.
Bob Alston
>You can't use VBA when creating an Access database that you are going
>to push up to SharePoint. VBA, Action Queries and traditional Access
>macros are not supported by Access Services.
Not really. IF you are going to use the Access rich client front end,
then you can have non-web forms and non-web reports and queries, macros,
modules and vba in the access database you publish to the web. Then the
user downloads that app and runs in windows. I have done this and it
works slick.
If however you intend to run the forms and reports in Sharepoint, then I
would agree with the post.
Bob
David W. Fenton
> A SharePoint Front
> End server is simply the access point that a user connects to to
> then get at whatever data you are trying to make available.
True up to Access/Sharepoint 2010, which is the subject of this
discussion.
The new version offers new features, including the capability I've
been quizzing Albert about.
David W. Fenton
> I hope this is making some sense within the context of the thread.
Your comments are only partially applicable to the version of
Sharepoint that this thread is discussing. That is, all the
capabilities of previous versions of Sharepoint remain, but are
vastly expanded with Access services.
You might spend some time going back to the numerous threads about
Access 2010 and Sharepoint 2010 in this newsgroup, mostly launched
by valuable postings from Albert Kallal. Once you get caught up on
the discussion, you'll regret what you've said here, as it's
incorrect.
David W. Fenton
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> message news:DhITm.85021$Xf2....@newsfe12.iad...
>> "Daniel A. Galant" <daniel...@mindsharp.com> wrote in message
>> news:OtUQ35Fe...@TK2MSFTNGP05.phx.gbl...
>>
>>> The front ends don't sync to anything, they pull data from a
>>> backend SQL server.
>>
>> Actually, with SharePoint, they now do.....
>>
>> Right, but we not talking about the data here, we talking about
>> syncing changes to the applications.
>>
>> Individual parts of the application (forms, reports, code) after
>> being modified can thus be synced to the copy sitting on
>> SharePoint. This is NOT the whole application being changed, but
>> ONLY the parts that have been worked on.
>
> This is still data that is stored inside of SQL. Just as if I
> added a new column to a list or library. No argument.
No, it's not stored in SQL Server. It's like collaboration with
other document types (Word, Excel, etc.), in that the document (in
the case, an ACCDB) is stored on the Sharpoint server (not in SQL
Server or as Sharepoint lists), and Access Services manages
synchronizing design changes to the ACCDB.
[]
>> Now, the above is generally assume to be a web based application
>> in ms-access. (just to get you up to speed, access 2010 allows
>> 100% browser based (web) applications to be built using
>> SharePoint 2010).
>>
>> However, since ms-access allows a mix of both VBA forms (non
>> web), and also 100% web forms, the above automatic "replication"
>> or "deployment" system CAN ALSO be used for 100% non web based
>> applications. (but, to be clear, you actually are talking about a
>> web based application with VBA forms in it). You can also upsize,
>> or setup linked tables to SharePoint lists in ms-access, but
>> that's not what we are talking about.
>>
> You can't use VBA when creating an Access database that you are
> going to push up to SharePoint. VBA, Action Queries and
> traditional Access macros are not supported by Access Services.
Not for web publication, but for distribution, it's still possible.
Albert makes this distinction explicitly in his discussions about
web vs. client forms.
You're basically calling Albert a liar. I don't know who the hell
you are are, but I know Albert, and I believe him and not you.
Bob Alston
>>> Individual parts of the application (forms, reports, code) after
>>> being modified can thus be synced to the copy sitting on
>>> SharePoint. This is NOT the whole application being changed, but
>>> ONLY the parts that have been worked on.
>> This is still data that is stored inside of SQL. Just as if I
>> added a new column to a list or library. No argument.
>
> No, it's not stored in SQL Server. It's like collaboration with
> other document types (Word, Excel, etc.), in that the document (in
> the case, an ACCDB) is stored on the Sharpoint server (not in SQL
> Server or as Sharepoint lists), and Access Services manages
> synchronizing design changes to the ACCDB.
>
dat/lists etc. are themselves stored in SQL server?
bob
Rick Brandt
> No, it's not stored in SQL Server. It's like collaboration with
> other document types (Word, Excel, etc.), in that the document (in
> the case, an ACCDB) is stored on the Sharpoint server (not in SQL
> Server or as Sharepoint lists), and Access Services manages
> synchronizing design changes to the ACCDB.
I believe all such "documents" are stored in a SQL Server BLOB field so
they are technically in a SS table.
Albert D. Kallal
> You can't use VBA when creating an Access database that you are going to
> push up to SharePoint. VBA, Action Queries and traditional Access macros
> are not supported by Access Services.
>
Correct. However, those forms and changes ARE saved on SharePoint!
The forms are SERIALIZED out just like when we use source code control.
(ie: saved out as separate objects). (look up the word serialized if you
want more on this term).
Thus, much of the check in/check out features of SharePoint are at work
here.
This stuff is so very new to a LOT OF people here. I am not worried when
some here are not quite up to speed. It just means we have a good amount
of education that needs to occur here. So, the flurry of new questions on
SharePoint and access are quite "enjoyable" to say the least!
So, as mentioned, published Access applications can
LEGALLY have a mix of VBA forms, and WEB only forms. BOTH TYPES of forms are
allowed in web applications. However, as mentioned ONLY the web forms can be
used by "access web services".
Changes to web only forms, or a changes to a VBA only forms are saved by
sync.
"client only VBA objects" are saved and synced.
Because of the above ability to sync parts of the application, we can now
"boot leg" this feature of SharePoint and Published access applications and
use this feature to "distribute" our rich VBA applications.
To be 100% specific clear here, we talking about a web based application but
that application in our current example has no web forms. It is comprised of
VBA only forms.
I should point out that just like using source code control for ms-access
applications EACH object is saved SEPARATE on the server. I think pointing
out this issue
will likely answer some questions here, but at the same time raise more
questions! (I am debating if it good to even show this screen shot!!)
Anyway, I will....
Here is a screen shot of the SharePoint site:
Note that this screen shot is from the CTP beta preview, and it shows the
VBA form as a web form, but that is incorrect. However note the yellow hand
I put in that is pointing to a VBA ONLY form in this list. They are saved
in the web site along with web forms that access creates after publishing.
I have not yet setup a new SharePoint server, and when I do...I will spend
time resolving this issue of how to "over write" existing individual forms,
or a reverting to a "saved" pervious versions we have on the hard drive.
There is also a series of steps one can take to un-publish an application,
but it rather painful and again how to do this is another long story/post
I shall no doubt have to make.
I have become VERY busy with work and the holidays, so it going to be about
2
weeks before I can get back to playing with SharePoint (I expect then is
when I should have a new SharePoint system up and running).
Salad
> There is also a series of steps one can take to un-publish an application,
> but it rather painful and again how to do this is another long story/post
> I shall no doubt have to make.
>
> I have become VERY busy with work and the holidays, so it going to be about
> 2
> weeks before I can get back to playing with SharePoint (I expect then is
> when I should have a new SharePoint system up and running).
>
I am curious as to how table changes would be made. I assume there'd be
no problem with adding a new table. But what if you had a table with a
field LastName that is 5 chars in length and you want to expand to 20,
or add a new field. Is it seemless?
Albert D. Kallal
news:ht-dnd1feLuyvrzW...@earthlink.com...
Well, I should point out for this discussion we were talking NOT about
SharePoint data tables in this example.
However, for linked SharePoint tables? Table changes in the client side to
SharePoint occur in real time and are NOT held back by use of the sync
feature.
In other words, sync is NOT applying to table design changes for SharePoint
lists
(talking about upsized data tables from access to SharePoint lists in a WEB
application).
In other words, you add a new column, add a new index, set an existing index
as unique etc, change the length of a field, add a new calculated column,
you are
doing this on the live data and in real time. There is no need sync (shall I
say no ability! to sync) when modifying the table structures in the access
client app that is connected to the tables (list) on the SharePoint server.
Albert D. Kallal
No, I was not referring to the actual SharePoint data store.
I was referring to that you can legally have split databases with the back
end data as Sql server, (or any odbc server), or the back end can be
ms-access back ends. This setup is possible now with a "published" web
access application. But, those links will ONLY work for client side (non
web) based objects (forms, reports query, VBA code etc.) that happens to
exist in that published access application. So, we can publish our
applications and NOT use SharePoint as where the data for the access
application will reside (but, this only works for non web forms).
Unfortunately, for access web services, you are not allowed external data
sources (even the BDC (business data catalog - this was cut quite late in
the program....).
You can however use .net and "sink" the access forms into custom .net code
that pulls data from other sources into lists (but, this would be a whole
other ball game/post).
At the end of the day, it is true that darn near everything in SharePoint is
ultimately saved in a super sql database server "blob" of a database. To be
clear, I was not making any reference to the issue that SharePoint uses sql
server as an data store for almost everything....
Salad
Sharepoint server (after publishing) and the links I might have would be
on the local machine pointing to those published tables on the
Sharepoint server.
One can change the table structure without "exclusive use"? I guess
that question got me started on my first post.
David W. Fenton
If so, it's still completely irrelevant, since we weren't talking
about data storage.
David W. Fenton
news:hfpdfo$a1i$2...@news.eternal-september.org:
Even so, it's not relevant to the current topic of discussion, which
was completely missed by the correspondent in question.
Bob Alston
bob
Daniel A. Galant
else, I have only been following the thread on the
microsoft.public,sharepoint.general forum. That particular thread topic
happens to be "Using SharePoint 2010 for data storage...." so forgive me if
I thought this had something to do with actually storing data.
--
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns9CDD99E5F6E55f9...@74.209.136.91...
Albert D. Kallal
>
> Count me confused. I thought the data tables were stored in/on the
> Sharepoint server (after publishing) and the links I might have would be
> on the local machine pointing to those published tables on the Sharepoint
> server.
>
> One can change the table structure without "exclusive use"? I guess that
> question got me started on my first post.
>
Yes, you can change tables (In fact, I not sure you even need exclusive use
either).
Hence, after you published, design changes to web forms, web reports, web
quires etc are still changed on the client side (and, then you hit sync to
send up those changed objects).
However, for those linked tables, you can also modify the designs in the
client side. If you add new columns, or modify indexes etc, those changes
occur while your in design mode and you do NOT have to hit the sync button
to make tables changes occur. So, after you published, yes, the tables/data
are located on SharePoint, but you still use the tools in ms-access to
modify the table structures.
I have not tested this, but I do believe some changes are allowed while
users are even working on the data. This would not be the first such system
I worked on over the years that allows changes to data structures while
users are working on the data. I suspect that deleting a column requires
exclusive use, but adding new columns should work even while other users are
working. I have to test this. So, I am not 100% sure of the exclusive
issue(s), but I am 100% sure about changing tables and not needing to "sync"
when you do modify the structure of the tables (of which are now linked to
SharePoint).
Salad
Ok. I opened up my local mdb and the table. It was linked to
Sharepoint. I then added a column to the table in SharePoint. Then I
did a Record/Refesh in the mdb and no new column. When I closed the
table and reopened it the new field existed. So exclusive use was not
required. I opened up the web page that had a data entry form based on
the sharepoint table and then I added another column and it didn't
affect the web page either.
Albert D. Kallal
>>
> Ok. I opened up my local mdb and the table. It was linked to Sharepoint.
> I then added a column to the table in SharePoint.
Right, be we were talking about making the modifying in the client
(since modifying forms, etc. needs one to "sync" the application
after changes been made).
Keep in mind, that linked tables to SharePoint as oppose to published
applications are still somewhat different. Published applications ALLOW
the table designs to be modified from the access client. Where as a
linked tables to SharePoint does NOT allow one to make changes to
the table.
> Then I did a Record/Refesh in the mdb and no new column. When I closed the
> table and reopened it the new field existed. So exclusive use was not
> required.
Well, the above is likely same behavior would be seen if you had a linked
table to
sql server. You have to re-link to see the new column. The above
observation
still does not preclude the issue of exclusive access to the table being
required.
So, doing the reverse was really the question here (making
the changes to the tables in ms-access that exist on SharePoint).
> I opened up the web page that had a data entry form based on the
> sharepoint table and then I added another column and it didn't affect the
> web page either.
As mentioned, I don't believe you need exclusive table rights to modify
or add columns, but I have to test/try this. No question you can modify
or add columns to the SharePoint list using the SharePoint options, but
the question was can you do the same from the access 2010 client?
Do keep
in mind it only access 2010 that has this "new" ability to allow table
design changes from the client AFTER the application been published.
Regardless of the above issues, using of the "sync" option is NOT required
or needed to send up table design changes...they occur in real time and
thus can't be done in "off line" mode.
David W. Fenton
> Excuse me David, but maybe there has been more of this discussion
> somewhere else, I have only been following the thread on the
> microsoft.public,sharepoint.general forum. That particular thread
> topic happens to be "Using SharePoint 2010 for data storage...."
> so forgive me if I thought this had something to do with actually
> storing data.
Maybe you should watch more carefully what threads you are posting
in.
There has been really extensive and lengthy discussion of all sorts
of A2010/Sharepoint issues in comp.databases.ms-access, which is the
newsgroup I am seeing this article [cross-]posted in. Maybe you
should check the newsgroups header before posting a reply.
Daniel A. Galant
I have no idea what burr flew up your.... In most cases these forums are
used for an exchange if information, ideas and learning. In looking over the
posts that I have been replying to etc, none of my comments are out of
bounds, out of line (except maybe some of my comments to you in response to
your attitude... ) or not relevant. Again, it seems pretty clear to me that
you are unaware of how SharePoint works. Publishing an Access database to
SharePoint, with 2010, will still have to play by SharePoint rules, meaning
that the Access application becomes a series of SharePoint lists and forms,
which, regardless of what you want to believe, reside on the backend SQL
server. SharePoint is not a front end for Access, at least not according to
the product folks I have spoken to.
The fact that this is being cross posted is also irrelevant to your
comments. I have been commenting on the thread as it appears in the
SharePoint forums, so perhaps you had better take some of your own advice.
--
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns9CDFA17B523F4f9...@74.209.136.82...
David W. Fenton
> I have no idea what burr flew up your.... In most cases these
> forums are used for an exchange if information, ideas and
> learning. In looking over the posts that I have been replying to
> etc, none of my comments are out of bounds, out of line (except
> maybe some of my comments to you in response to your attitude... )
> or not relevant. Again, it seems pretty clear to me that you are
> unaware of how SharePoint works. Publishing an Access database to
> SharePoint, with 2010, will still have to play by SharePoint
> rules, meaning that the Access application becomes a series of
> SharePoint lists and forms, which, regardless of what you want to
> believe, reside on the backend SQL server. SharePoint is not a
> front end for Access, at least not according to the product folks
> I have spoken to.
You are calling Albert Kallal a liar, as he has said that publishing
an Access app in the way described in this thread (i.e., no data,
just the Access app, with no web forms and no Sharepoint hosting)
does *not* convert the app or its data to Sharepoint lists, but
instead stores the file in a BLOB field.
If you know this to be false or misleading, please provide the
documentation for your assertion that Albert is wrong. You will
perhaps want to review the history of this thread in more detail
than you seem to have already done, given how off-the-mark your
replies have been in terms of the subject being discussed in this
thread.
> The fact that this is being cross posted is also irrelevant to
> your comments. I have been commenting on the thread as it appears
> in the SharePoint forums, so perhaps you had better take some of
> your own advice.
Had you read the history of the thread you were posting to, you
would have realized that the comments you posted were completely
off-base.
I await your documentation for your assertions that contradict
Albert, or your retraction and apology.
Daniel A. Galant
this entire thread, and only this thread as it is the only one I have been
posting in or are concerned with. I have also watched, again, the relevant
posted video that was pointed out by Albert, in his response to Bob, early
on in this thread to see if I perhaps misunderstood its content. In going
over the contents of all this, the only one who is out of line here David is
you. At no time have I called Albert a liar, I would love for you to point
out where in this thread I have done so. Also, you have stated:
"If so, it's still completely irrelevant, since we weren't talking
about data storage."
I would like to bring to your attention this from the original post of this
thread.
"Again my interest is data on sharepoint 2010 and use normal windows/
Access clients on each user's PC. I am not trying to take about the
new web forms and reports which run in a browser."
Which was further expressed again:
"There are a few subthreads of this overall thread. My original object
was and is to pursue using Access 2010 as a rich client front end to
data that is stored/hosted in Sharepoint."
This was in response to my first posting in this thread. Again, I really
would like to stress, this thread. So as far as I can see David, it is you
who are out of line with your attacks on me and perhaps should apologize. Is
it possible that during this discussion I have stated something that is
incorrect? Perhaps, but then isn't that the purpose of these forums? To
learn? Would you like me to point out the times, in this thread, you have
stated something that is incorrect? Did I call you a liar? No, you are
simply incorrect in your thinking.
If you want to talk about a split Access database, using Access 2010 and
SharePoint 2010, where the data still sits in Access but the front end
application is now in SharePoint, fine. I suggest you go and review the
video again.
When you split the database like this, the application part becomes a
SharePoint site, pointing to the data that still sits in your Access
database. No problem, this can be done with a number of data sources now
with SharePoint 2007. Let's not, however, confuse our terms here. There is a
difference between an Access application front end and a SharePoint Front
End server. I assume you are quite familiar with the first, since you are an
Access person. The SharePoint Front End server is the web access point where
users connect to a SharePoint farm. The WFE responds to users requests for
information by building pages and sending that data to the clients browser.
These pages are made up of many components, not a discussion for this
thread, but the elements of which can be pulled from a number of locations.
When you publish the Access front end application, those elements are turned
into a SharePoint site with the corresponding required lists, forms,
workflows etc. The source data, yes, still resides in your backend database,
be it Access or SQL if you moved it there. None the less, these lists etc,
that now make up your front end for the app, are SharePoint. SharePoint
sites live in content databases, on SQL. The lists are tables in this
content database, that has not changed, even in the new world of 2010.
If this is not the case, I welcome Albert, or anyone, educating me on how
this now works differently. I'm not offended by this, I enjoy learning.
David W. Fenton
> Ok, I'll try and make this as civil as I can. I have indeed gone
> through this entire thread,
It does not appear to me that you have done that at all. As outlined
below, I've followed the direct lineage of your own post to which
I'm replying here, and the References line demonstrates quite
clearly that the topic was pretty clearly front-end distribution
from the SECOND post in the References line of YOUR OWN POST.
> and only this thread as it is the only
> one I have been posting in or are concerned with. I have also
> watched, again, the relevant posted video that was pointed out by
> Albert, in his response to Bob, early on in this thread to see if
> I perhaps misunderstood its content.
You are, apparently, not actually examining the content of the
discussion with a proper newsreader that threads posts based on the
References line. If you had, you wouldn't be making the claims that
you are making, as the content of the posts in the References header
of your own post contradict what you're saying.
> In going over the contents of
> all this, the only one who is out of line here David is you. At no
> time have I called Albert a liar,
I didn't say you called him a liar. I said you have contradicted his
assertions, and that you're either saying that he's mistaken (i.e.,
a liar) or you are yourself mistaken.
> I would love for you to point
> out where in this thread I have done so.
Specifically:
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in
news:Xns9CDCA92C1E2CFf9...@74.209.136.98:
[this is a quotation from your MessageID:
<en4uXxQe...@TK2MSFTNGP05.phx.gbl>)]
>> You can't use VBA when creating an Access database that you are
>> going to push up to SharePoint. VBA, Action Queries and
>> traditional Access macros are not supported by Access Services.
>
> Not for web publication, but for distribution, it's still
> possible. Albert makes this distinction explicitly in his
> discussions about web vs. client forms.
>
> You're basically calling Albert a liar. I don't know who the hell
> you are are, but I know Albert, and I believe him and not you.
That was a direct response to a claim of yours that I said
contradicts what Albert has said. Is Albert correct or are you? If
Albert is, then you owe him an apology.
> Also, you have stated:
>
> "If so, it's still completely irrelevant, since we weren't talking
> about data storage."
>
> I would like to bring to your attention this from the original
> post of this thread.
>
> "Again my interest is data on sharepoint 2010 and use normal
> windows/ Access clients on each user's PC. I am not trying to
> take about the new web forms and reports which run in a browser."
And if you look at Albert's first reply to that (MessageID:
<qoHSm.49392$ky1....@newsfe14.iad>) you'll see that his first line
is:
> You even use SharePoint to pull down an application that is split.
And he follows that with:
> In other words, the data can reside on a backend accDB file
> sitting on a server, and the front end pulled down from
> SharePoint (but, this case, this means you suing a spit
> system, and that is NOT appropriate for wireless or a wan).
If you then follow the MessageIDs in the References to your own
post, next comes a reply from Bob Alston
(<1JHSm.38493$cX4....@newsfe10.iad>), and then a reply from Albert
(<uAAQFBkd...@TK2MSFTNGP02.phx.gbl>), both of which are quite
clearly discussing the scenario of using Sharepoint to distribute
a front end that is linked to a local ACCDB back end.
Then I replied to Albert (MessageID:
<Xns9CD9A9BF68F92f9...@74.209.136.99>):
> Albert, can you look at my other post, replying to Bob, asking
> about version control issues with synchronizing a published app?
At this point, is there any doubt what we are talking about?
These posts are directly in the lineage of the post to which I am
now replying, i.e., the part of the thread where you interjected
this (MessageID: <OtUQ35Fe...@TK2MSFTNGP05.phx.gbl>):
> Ok, I'll admit that I've been trying to follow a bit of this
> discussion and I'm completely lost here as to what you are trying
> to do.
...and then went off on an unrelated discussion, contradicting what
Albert had been outlining:
> A SharePoint Front End server is simply the access point that a
> user connects to to then get at whatever data you are trying to
> make available. The front ends don't sync to anything, they pull
> data from a backend SQL server.
This is wrong. Simply wrong, which is why I asked you to explain
your contradiction of Albert.
[]
> This was in response to my first posting in this thread. Again, I
> really would like to stress, this thread. So as far as I can see
> David, it is you who are out of line with your attacks on me and
> perhaps should apologize.
Follow the MessageIDs and explain to me how I have incorrectly
described the content of the particular messages to which you have
replied, which are clearly in a lineage that was discussion
front-end distribution via Sharepoint, something that you deny is
possible.
> Is it possible that during this
> discussion I have stated something that is incorrect? Perhaps, but
> then isn't that the purpose of these forums? To learn? Would you
> like me to point out the times, in this thread, you have stated
> something that is incorrect? Did I call you a liar? No, you are
> simply incorrect in your thinking.
Go back and READ THE THREAD. You apparently have not done so thus
far, or have done so in a completely haphazard way that doesn't
represent the actual order of the replies involved.
> If you want to talk about a split Access database, using Access
> 2010 and SharePoint 2010, where the data still sits in Access but
> the front end application is now in SharePoint, fine. I suggest
> you go and review the video again.
Bob Alston and I have discussing that topic IN THIS VERY THREAD. And
you pop in denying that it can be done.
> http://blogs.msdn.com/access/archive/2009/12/02/the-access-show-man
> aging-access-databases-with-sharepoint.aspx
>
> When you split the database like this, the application part
> becomes a SharePoint site, pointing to the data that still sits in
> your Access database.
You are going off on the tangent again, ignoring what Albert has
been talking about.
[tangential content omitted, as it just perpetuates your fundamental
misunderstanding of the topic of the thread and your apparent
failure to actually read Albert's posts in the thread that discuss
what you claim is impossible]
> If this is not the case, I welcome Albert, or anyone, educating me
> on how this now works differently. I'm not offended by this, I
> enjoy learning.
Just read the thread. It's all there.
Daniel A. Galant
never said that splitting out the front end of your Access database and
publishing it via Access services on SharePoint was impossible. it certainly
can be done using Access 2010 and SharePoint 2010. So you misinterpreted
something somewhere in that regard. Secondly,
>
> I didn't say you called him a liar. I said you have contradicted his
> assertions, and that you're either saying that he's mistaken (i.e.,
> a liar) or you are yourself mistaken.
>
You certainly did. This is where you began...
"You're basically calling Albert a liar. I don't know who the hell
you are are, but I know Albert, and I believe him and not you."
Also, in that very same post you responded to my comment,
>>
> You can't use VBA when creating an Access database that you are
> going to push up to SharePoint. VBA, Action Queries and
> traditional Access macros are not supported by Access Services.
by saying,
>Not for web publication, but for distribution, it's still possible.
>Albert makes this distinction explicitly in his discussions about
>web vs. client forms.
Which was all well and good and made the distinction I was unaware of. Had
you been civil about it and stopped there without adding your attack on me,
I have a feeling this would have been avoided. What you said at that point
was fine. it was my understanding that when publishing to SharePoint, the
compatibility checker looks for these things and reports them as illegal
content. As I also mentioned, I have not played with this, and if I was
wrong about that cool. I was referring to what you call web publication, and
YOU even agreed with me on that point.
So maybe we can let this drop as I have a feeling we are the only ones even
looking at this anymore.
--
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns9CE2AB72B2CF9f9...@74.209.136.98...
David W. Fenton
> Had
> you been civil about it and stopped there without adding your
> attack on me, I have a feeling this would have been avoided.
In other words, you're one of those sensitive types who gets
offended easily.
Duly noted.
Daniel A. Galant
--
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns9CE3E7A2E7CBEf9...@74.209.136.97...
Keith Wilby
news:903C9FE7-0432-45C5...@microsoft.com...
> Yeah, and I also have to have the last word.
>
>
Daniel,
Don't beat yourself up about David's lack of courtesy and manners when he
responds to a posting he doesn't like. It is his failing, not yours.
Regards,
Keith.