Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms

Some time ago, Albert Kallah wrote that with Access 2010 it was
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

0
Bob
12/6/2009 4:40:31 AM
sharepoint.general 599 articles. 0 followers. Follow

49 Replies
1653 Views

Similar Articles

[PageSpeed] 13

You even use SharePoint to pull down an application that is split.

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
pleaseNOOSpamKallal@msn.com




0
Albert
12/6/2009 5:35:18 AM
You even use SharePoint to pull down an application that is split.

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
pleaseNOOSpamKallal@msn.com





0
Albert
12/6/2009 5:37:59 AM
Albert D. Kallal wrote:
> You even use SharePoint to pull down an application that is split.
> 
> 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).
> 
> 
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
0
Bob
12/6/2009 5:57:12 AM
Bob Alston wrote:
> 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
0
Bob
12/6/2009 6:35:23 AM
"Bob Alston" <bobalston9@yahoo.com> wrote in message 
news:1JHSm.38493$cX4.19748@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...

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


0
Albert
12/6/2009 6:49:32 AM
"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
news:qoHSm.49392$ky1.44754@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/
0
David
12/6/2009 9:29:45 PM
Bob Alston <bobalston9@yahoo.com> wrote in
news:QgISm.38494$cX4.11639@newsfe10.iad: 

> 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                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/6/2009 9:37:44 PM
"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
news:uAAQFBkdKHA.5136@TK2MSFTNGP02.phx.gbl: 

> 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? 

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/6/2009 9:41:10 PM
"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message
news:Xns9CD9A9BF68F92f99a49ed1d0c49c5bbb2@74.209.136.99...
> "Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
> news:uAAQFBkdKHA.5136@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?

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    (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com


0
Albert
12/7/2009 11:13:09 AM
"David W. Fenton" <XXXusenet@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.

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    (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com


0
Albert
12/7/2009 11:29:26 AM
"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CD9A7CFE7F3Ff99a49ed1d0c49c5bbb2@74.209.136.99...
> "Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
> news:qoHSm.49392$ky1.44754@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.

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


0
Albert
12/7/2009 11:33:25 AM
"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
news:#XzrJCzdKHA.1592@TK2MSFTNGP06.phx.gbl: 

> "David W. Fenton" <XXXusenet@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                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/8/2009 3:15:44 AM
"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
news:9r5Tm.75090$W77.73956@newsfe11.iad: 

> "David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message
> news:Xns9CD9A9BF68F92f99a49ed1d0c49c5bbb2@74.209.136.99...
>> "Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
>> news:uAAQFBkdKHA.5136@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. 

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/8/2009 3:23:46 AM
"David W. Fenton" <XXXusenet@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?

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

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


0
Albert
12/8/2009 8:26:29 AM
"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
news:W4oTm.17342$_b5.5426@newsfe22.iad: 

> "David W. Fenton" <XXXusenet@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. 

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/8/2009 9:09:06 PM
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.

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CDBA44DF911Ff99a49ed1d0c49c5bbb2@74.209.136.90...
> "Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
> news:W4oTm.17342$_b5.5426@newsfe22.iad:
>
>> "David W. Fenton" <XXXusenet@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.
>
> -- 
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/ 

0
Daniel
12/8/2009 11:30:43 PM
Daniel A. Galant wrote:
> 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.
> 
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.  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/ 


http://dmoffat.wordpress.com/

HTH

bob
0
Bob
12/8/2009 11:49:34 PM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in message 
news:OtUQ35FeKHA.4880@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...

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


0
Albert
12/9/2009 7:25:23 AM
Fine, let's not forget where SharePoint is storing all this info, in SQL. 
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" <bobalston9@yahoo.com> wrote in message 
news:eCBTm.45381$ZF3.12828@newsfe13.iad...
> Daniel A. Galant wrote:
>> 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.
>>
> 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.  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/
>
> http://dmoffat.wordpress.com/
>
> HTH
>
> bob 

0
Daniel
12/9/2009 8:04:54 PM
See inline...

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in message 
news:DhITm.85021$Xf2.78104@newsfe12.iad...
> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in message 
> news:OtUQ35FeKHA.4880@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.

> 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...
>
> -- 
> Albert D. Kallal    (Access MVP)
> Edmonton, Alberta Canada
> pleaseNOOSpamKallal@msn.com
>
> 
0
Daniel
12/9/2009 8:15:21 PM
Daniel A. Galant wrote:

 >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
0
Bob
12/9/2009 9:16:08 PM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
news:OtUQ35FeKHA.4880@TK2MSFTNGP05.phx.gbl: 

> 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                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/9/2009 9:45:04 PM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
news:#AqAirQeKHA.3792@TK2MSFTNGP02.phx.gbl: 

> 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                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/9/2009 9:47:03 PM
>>> 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. 
> 
Is it possible that he was referring to the fact that the sharepoint 
dat/lists etc. are themselves stored in SQL server?

bob
0
Bob
12/9/2009 9:50:59 PM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
news:en4uXxQeKHA.5608@TK2MSFTNGP05.phx.gbl: 

> "Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
> message news:DhITm.85021$Xf2.78104@newsfe12.iad...
>> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in message
>> news:OtUQ35FeKHA.4880@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. 

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/9/2009 9:51:45 PM
David W. Fenton wrote:
> 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.
0
Rick
12/9/2009 11:56:28 PM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in message
news:en4uXxQeKHA.5608@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.
>

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:

http://nrfu5a.bay.livefilestore.com/y1pfBMYrXvv9dr8P0T5X6jITlOluooxm7H5KffNiSsf5V8I6JCymOyaJEr-W4iwuH9wvfy3rKhIMAC8ftDwz5CoTwjGCCvYsIn5/SharePointFiles.png

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

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




0
Albert
12/10/2009 12:36:26 PM
And I don't know who are either, but I suggest you take a deep breath and 
relax. I'm not calling anyone a liar. I will, however, tell you that you are 
flat out wrong when you say that files like Word etc are stored on the 
SharePoint server. Go and take a look, you won't find them. When you a file, 
any file, to SharePoint it is stored as an entry in the corresponding 
library table in your SQL server where SharePoint will fetch it for you, and 
then pass it back to the corresponding application. This is why, for one 
thing, you don't store an Access database in SharePoint. you store a 
database inside of another database. When you publish an Access database to 
SharePoint, it creates corresponding lists and libraries, etc, as needed to 
replicate the structure of the database. These lists and libraries are now 
tables in your SQL content database that now store the data entries.

Furthermore, Albert seems to have understood my statement and didn't seem 
offended by it. Why are you?

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CDCA92C1E2CFf99a49ed1d0c49c5bbb2@74.209.136.98...
> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
> news:en4uXxQeKHA.5608@TK2MSFTNGP05.phx.gbl:
>
>
> 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.
>
> []
> 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.
>
> -- 
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/ 

0
Daniel
12/10/2009 1:31:15 PM
I don't regret anything I've said here. SharePoint 2010 has indeed made a 
lot of changes and improvements over the current version. Certain 
functionality still remains however. I've already mentioned that I'm not an 
Access person, I'm a SharePoint person.

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CDCA860673E5f99a49ed1d0c49c5bbb2@74.209.136.98...
> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
> news:#AqAirQeKHA.3792@TK2MSFTNGP02.phx.gbl:
>
>> 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                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/ 

0
Daniel
12/10/2009 1:38:57 PM
I should proofread my posts before hitting send.

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in message 
news:F4E0B6A9-0483-44A5-B112-5F429D6F20CC@microsoft.com...
> And I don't know who are either, but I suggest you take a deep breath and 
> relax. I'm not calling anyone a liar. I will, however, tell you that you 
> are flat out wrong when you say that files like Word etc are stored on the 
> SharePoint server. Go and take a look, you won't find them. When you a 
> file, any file, to SharePoint it is stored as an entry in the 
> corresponding library table in your SQL server where SharePoint will fetch 
> it for you, and then pass it back to the corresponding application. This 
> is why, for one thing, you don't store an Access database in SharePoint. 
> you store a database inside of another database. When you publish an 
> Access database to SharePoint, it creates corresponding lists and 
> libraries, etc, as needed to replicate the structure of the database. 
> These lists and libraries are now tables in your SQL content database that 
> now store the data entries.
>
> Furthermore, Albert seems to have understood my statement and didn't seem 
> offended by it. Why are you?
>
> -- 
> Daniel A. Galant
>
> Imagine what we could be... if we could just imagine.
>
> "David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
> news:Xns9CDCA92C1E2CFf99a49ed1d0c49c5bbb2@74.209.136.98...
>> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
>> news:en4uXxQeKHA.5608@TK2MSFTNGP05.phx.gbl:
>>
>>
>> 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.
>>
>> []
>> 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.
>>
>> -- 
>> David W. Fenton                  http://www.dfenton.com/
>> usenet at dfenton dot com    http://www.dfenton.com/DFA/
> 
0
Daniel
12/10/2009 2:41:41 PM
Albert D. Kallal wrote:

> 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?
0
Salad
12/10/2009 4:32:58 PM
"Salad" <salad@oilandvinegar.com> wrote in message 
news:ht-dnd1feLuyvrzWnZ2dnUVZ_rWdnZ2d@earthlink.com...
> Albert D. Kallal wrote:
>
>> 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?

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    (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com


0
Albert
12/10/2009 4:58:08 PM
"Bob Alston" <bobalston9@yahoo.com> wrote in message 
news:0ZUTm.26638$gd1.11362@newsfe05.iad...
>
>>>> 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.
> Is it possible that he was referring to the fact that the sharepoint 
> dat/lists etc. are themselves stored in SQL server?

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

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


0
Albert
12/10/2009 5:10:07 PM
Albert D. Kallal wrote:
> "Salad" <salad@oilandvinegar.com> wrote in message 
> news:ht-dnd1feLuyvrzWnZ2dnUVZ_rWdnZ2d@earthlink.com...
> 
>>Albert D. Kallal wrote:
>>
>>
>>>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?
> 
> 
> 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.
> 
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.



0
Salad
12/10/2009 5:31:16 PM
Bob Alston <bobalston9@yahoo.com> wrote in
news:0ZUTm.26638$gd1.11362@newsfe05.iad: 

> 
>>>> 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. 
>> 
> Is it possible that he was referring to the fact that the
> sharepoint dat/lists etc. are themselves stored in SQL server?

If so, it's still completely irrelevant, since we weren't talking
about data storage. 

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/10/2009 8:07:42 PM
Salad wrote:
> Albert D. Kallal wrote:
> 
>> 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?
Suggest you try it and report to all of us.

bob
0
Bob
12/10/2009 8:29:15 PM
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.

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CDD99E5F6E55f99a49ed1d0c49c5bbb2@74.209.136.91...
> Bob Alston <bobalston9@yahoo.com> wrote in
> news:0ZUTm.26638$gd1.11362@newsfe05.iad:
>
>>
>>>>> 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.
>>>
>> Is it possible that he was referring to the fact that the
>> sharepoint dat/lists etc. are themselves stored in SQL server?
>
> If so, it's still completely irrelevant, since we weren't talking
> about data storage.
>
> -- 
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/ 

0
Daniel
12/10/2009 8:44:34 PM
"Salad" <salad@oilandvinegar.com> wrote in message

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

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


0
Albert
12/10/2009 9:29:27 PM
Bob Alston wrote:
> Salad wrote:
> 
>> Albert D. Kallal wrote:
>>
>>> 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?
> 
> Suggest you try it and report to all of us.
> 
> bob

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.
0
Salad
12/10/2009 11:12:48 PM
"Salad" <salad@oilandvinegar.com> wrote in message

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


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




0
Albert
12/11/2009 9:24:30 AM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
news:u68FWmdeKHA.5136@TK2MSFTNGP02.phx.gbl: 

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

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/12/2009 8:52:24 PM
David,

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" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CDFA17B523F4f99a49ed1d0c49c5bbb2@74.209.136.82...
> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
> news:u68FWmdeKHA.5136@TK2MSFTNGP02.phx.gbl:
>
>> 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.
>
> -- 
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/ 

0
Daniel
12/14/2009 2:26:36 AM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
news:2284B36A-9F0C-4C3E-A30F-0A52DCD32A17@microsoft.com: 

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

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/14/2009 8:22:49 PM
Ok, I'll try and make this as civil as I can. I have indeed gone through 
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.

http://blogs.msdn.com/access/archive/2009/12/02/the-access-show-managing-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. 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.

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

 

0
Daniel
12/15/2009 4:46:07 AM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
news:A0DBE0D6-E399-47DE-9B88-C4B5A339B728@microsoft.com: 

> 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" <XXXusenet@dfenton.com.invalid> wrote in
news:Xns9CDCA92C1E2CFf99a49ed1d0c49c5bbb2@74.209.136.98: 

[this is a quotation from your MessageID:
<en4uXxQeKHA.5608@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.44754@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.19748@newsfe10.iad>), and then a reply from Albert
(<uAAQFBkdKHA.5136@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:
<Xns9CD9A9BF68F92f99a49ed1d0c49c5bbb2@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: <OtUQ35FeKHA.4880@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.

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/15/2009 10:06:29 PM
I seriously don't think you understand at all what I have been saying. I 
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" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CE2AB72B2CF9f99a49ed1d0c49c5bbb2@74.209.136.98...
> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
> news:A0DBE0D6-E399-47DE-9B88-C4B5A339B728@microsoft.com:
>
>> 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" <XXXusenet@dfenton.com.invalid> wrote in
> news:Xns9CDCA92C1E2CFf99a49ed1d0c49c5bbb2@74.209.136.98:
>
> [this is a quotation from your MessageID:
> <en4uXxQeKHA.5608@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.44754@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.19748@newsfe10.iad>), and then a reply from Albert
> (<uAAQFBkdKHA.5136@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:
> <Xns9CD9A9BF68F92f99a49ed1d0c49c5bbb2@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: <OtUQ35FeKHA.4880@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.
>
> -- 
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/ 

0
Daniel
12/15/2009 11:14:20 PM
Daniel,

Sorry you had to put up with all this.  Absurd.

Thanks for all the other contributions to the SharePoint community.
0
Rob
12/16/2009 10:04:20 AM
"Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
news:934F47E9-AB41-4B8D-9A81-79358522EE31@microsoft.com: 

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

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
12/17/2009 4:01:45 AM
Yeah, and I also have to have the last word.

-- 
Daniel A. Galant

Imagine what we could be... if we could just imagine.

"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
news:Xns9CE3E7A2E7CBEf99a49ed1d0c49c5bbb2@74.209.136.97...
> "Daniel A. Galant" <daniel.galant@mindsharp.com> wrote in
> news:934F47E9-AB41-4B8D-9A81-79358522EE31@microsoft.com:
>
>> 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.
>
> -- 
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/ 

0
Daniel
12/17/2009 2:56:55 PM
Reply:

Similar Artilces:

Changing Cells and entering data in them
Thanks for the help again. Big thanks to Steve you've got me this far. I went out and bought a book, but it's like reading a foreign language. I was informed today that I can't have message boxes come up. I need to have the code point at the cells and if they are blank turn which ever one is blank red or if both are then both turn red then pause for each cell to be filled in. Cell F14 "Last Name" then automatically go to Cell F16 "First Name" on tab or enter. Basically if Cell F22 or F23 has an X in it, Cells F14 an F16 turn red and cell F14 has the focus...

Using Relative path for XML data file?
Is there a way to specify a relative path to an XML data file imported into Excel 2003? I am writing a web app that generates report data as XML for the user to download to their local machine. This data is to be consumed by an Excel reporting spreadsheet, which contains display-formatted tables and charts that are mapped to various data fields in an XML Map, which is in turn linked to the xml data file they will download. The idea is the user only needs to download the data for updates, not the whole spreadsheet. However, since I cannot predict the path where the user will store their...

Formula without using numbers after decimal in the answer
I have a formula that derives the answer from a figure with a decimal. I don't want to use the figures after the decimal. Is there a way to just use the whole number and omit the numbers after the decimal without having to manually key in all these numbers manually? Thanks, Mustang You can use the INT function. This 'rounds down' any number to th nearest integer, e.g. if A1=2.567, a formula in B2 of =INT(A1) return 2 HTH Bruc -- swatsp0 ----------------------------------------------------------------------- swatsp0p's Profile: http://www.excelforum.com/member.php?...

WCF Client serialization problem
I posted the problem on another forum, and to prevent duplicate posts, but get as many professionals as possible to look at it, I include the url in this post. Please help! http://stackoverflow.com/questions/2948657/migrating-webclient-to-wcf-wcf-client-serializes-parametername-of-method ...

Reporting from Project Server
I dont know if i need to ask this question here or in the Access section. I have an ODBC connection to the Project Server database so I can make reports through Access. Access' limit of 255 fields per table is causing me some trouble. for example, the MSP_VIEW_PROJ_PROJECTS_ENT table has well over 255 fields. Access only shows me the first 255 fields. how can I change that so I can see all the fields in that table? thanks, Hadi Hadi, I have not tried this yet it may be a viable option. Have your DBA create a view that pulls the key fields to this table and the specifi...

How do I see when new messages without outlook running?
Without Outlook 2003 constantly running, how do I send mail or know when I have new mail? two possible answers... 1) you don't or 2) you acquired a 3rd party app to occasionally poll your pop3/imap account "Leslie Adams" <Leslie Adams@discussions.microsoft.com> wrote in message news:D37C11C7-722C-4E91-9393-735A49C11701@microsoft.com... > Without Outlook 2003 constantly running, how do I send mail or know when I > have new mail? ...

using the journal on outlook
Once I link an email to the journal, can I still find that email in my mail box? I seem to be able to get to it only via the journal. If this is the way it is supposed to be, how do I remove it from the journal and get it back into my mail box? Am I just missing something? -- thanks, Independent Are you linking to the item or putting a copy into the journal item? Also, has the item been archived or not? "Independent" <Independent@discussions.microsoft.com> wrote in message news:868279F2-53C8-403A-97F5-604CEECD873C@microsoft.com... > Once I link an email to the journ...

data sort
ok now should be simple >> I need to sort by month on data that is held in format >> day/month so eg 1511 1510 3011 3010 now custom/ends with/ 11... does not work custom/ends with/ ??11.. or *11 does not work either contains 11 does not work (& would also be wrong if data set contained 1011) but still I am stumped so any help would be great cheers Alex I would be inclined to add a new, temporary field of formulas that pull off the right 2 digits, and sort by that: =RIGHT(A1,2) -- Jim Rech Excel MVP ...

explanation of codes in Visual Basic when creating User form
Hi, I am trying to create a user form in Visual Basic however I'm trying to teach myself by reading/watching tutorials. (www.contectures.o.ca, etc) A lot of the instructions I am seeing simply give the code rather than explain how to actually write one from scratch. So... I need to know what each 'term' means so I can understand how the codes work. Any help is much appreciated :) One of the first codes is for the Add button Private Sub cmdAdd_Click() Dim iRow As Long Dim ws As Worksheet Set ws = Worksheets("PartsData") What d...

Disable Secure Sockets Layer on exchange server when using RPC over HTTP
Hi im trying to enable RPC over HTTP to enable users to establish contact to my Excahger server 2003 over the internet. Now, I dont want to use SSL (security not that important) and i am told by this article that i can disable SSL in windows registry. Quote: Note While RPC over HTTP does not require Secure Sockets Layer, you must modify the registry to enable RPC over HTTP if you do not want to use Secure Sockets Layer. Microsoft recommends that you enable and require Secure Sockets Layer for your RPC over HTTP communications. At this address: http://support.microsoft.com/?id=833401 But i ...

How to automate increasing the form cache registry/file etc...
I want to roll out a batch file to make a number of tweaks to CRM The body of it would go REGEDIT /S Kerberosefix.reg REGEDIT /S ForceFormreload.reg REGEDIT /S OutlookFix.reg It would also rename OSA.exe to OSA.bad Remove OSA.exe From the startup menu I need help finding a way to use my batch file to increase the Outlook Form cache from the default 4MB to 50 MB.. This makes CRm more stable and faster for communications. I dont want to manually do this, as it time consuming, are my end users would not be reliable in doing it themselves. I also want to make another batch file or button that...

Pulling data from separate tabs
When charting in Excel 2002 is there a way to use sets of data from two different tabs within the same worksheet? For example, a spreadsheet contains separate tabs for prior year and current year data. Is there a way to reference the data or label series to pick up data from both? I tried pointing and clicking, and then typing the following as a reference for the axis labels: ='Prior Year'!$B$110:$M$110,'Current Year'!'$B$110:$M$110 but receive an error that I'm referring to an external worksheet. I've used the comma (') in the past to reference breaks ...

Formula for cross tab data filling
Hi All Excel 2003 How to using formula for data filling as below (Y/N) ? Sheet A Product A Product B Product C System A Y N Y System B Y Y N Sheet B System A Product A System A Product C System B Product A System B Product B moonhkt ...

Help with importing data
Can I have users fill in a form in Access and have that data be transferred and updated to a spreadsheet. Need for fill out several fields and then export to a specific spreadsheet and place that data into the cells that will update that cell (add to the total in that cell) of a spreadsheet. ...

Items in this message are still loading. Please wait a moment and try again.
Get this error message when trying to print an HTML email using Outlook 2002 10.6515.6735 SP3. I've seen lots of single post threads regarding this issue with no responses. The problem is, the moment lasts up to an hour. Are there any settings that can be tweaked to speed this process up? Could it possibly be a printer issue? This just recently started happening. Any suggestions are appreciated. I haven't ever experienced this but are you on a slow Internet connection? An hour is an awful long time (which I'm sure you know already) "Geoff" <geoff.warner@gmail...

Sent emails not logged in Sent Items (Outlook 2010)
I am using the Beta version of Outlook 2010 with Windows 7 Pro (64 bit). Sent emails are not logged in the Sent Items folder nor do saved drafts appear in the Drafts folder. I have confirmed that the relevant settings are checked in the Mail Settings. Any ideas what I can do to solve this problem? -- Stephen Newton "snewton" <snewton@discussions.microsoft.com> wrote in message news:F7345EA6-9E42-4DF7-AFA5-AD2DF2CA840D@microsoft.com... >I am using the Beta version of Outlook 2010 with Windows 7 Pro (64 bit). > Sent emails are not logged in the Sent I...

How to set "licence" for Access 2007 database?
Hi I developed an Access 2007 db to a client. Now I want to make a year based licence for that database that the client must pay if they want to continue using the database after year. It must be so that database cannot be used after this date. How I can accomplish this? Thanks! On Mon, 12 Apr 2010 13:14:17 -0700 (PDT), Sandroid <santeri.virtanen@gmail.com> wrote: >Hi > >I developed an Access 2007 db to a client. Now I want to make a year >based licence for that database that the client must pay if they want >to continue using the database after year. It mu...

Does Outlook use the DAV protocol?
I'm an Outlook Express user who wants to switch to Outlook. I received a notice from Microsoft that includes the following: "... as of June 30, 2008, Microsoft is disabling the DAV protocol and you will no longer be able to access your Hotmail Inbox via Outlook Express." Please tell me if this action by Microsoft will affect Outlook in the same manner, or am I free to make the switch. "BudV" <BudVitoff@(NO)att.(SPAM)net> wrote in message news:%230XUDi%23zIHA.2384@TK2MSFTNGP02.phx.gbl... > I'm an Outlook Express user who wants to switch to Outlook...

microsoft.public.access.conversion
...

Reply To Email after installing CRM Outlook Client
After installing the CRM Outlook Client, when opening an email and selecting REPLY, the current windows looses focus. I know this sounds minor but many of our power users are in the habit of hitting REPLY and typing without even looking at the screen. It is not until they look up do they realize that the window no longer has focus thus everything they thought they typed now has to be retyped. Has anyone seen this and know of a quick fix? Thanks in Advance -- Kenneth Clebak Kenneth Have you resolved this? I have the same problem, and it is VERY annoying. Saira "Kenneth Clebak&...

form fields not saving to table
I have created a database with a form and three of the fields are not saving the information to the table. I have checked the row and control sources and now at a loss and thoughts? As you scroll through existing records is the data of the table displayed? Post the SQL of the query or form source. -- Build a little, test a little. "Kim" wrote: > I have created a database with a form and three of the fields are not saving > the information to the table. I have checked the row and control sources and > now at a loss and thoughts? > > ...

Access to User Calendar
I have a user called small conference room that is used to schedule meetings on its calendar. I would like to link the calendar from our intranet site to the calendar with a UNC path. I am calling outlook: and I can get to my local mailbox and public folders but I am unable to connect to another users calendar. I am running Exchange 2003 and Outlook 2003. Is there some security modifications that need to be done? Any help is appreciated. Thanks, Steve I believe that you will need full mailbox rights. -- Ed Crowley MVP - Exchange "Protecting the world from PSTs and brick backups!&...

predict future data
Is there a way to create an XY line graph wih plotted data, yet leave room to predict future data on the axes? I can get the graph, but the x and y axes stop at the last data points, and I want those axes continued so that the existing data can be examined and future data predicted and plotted on the same graph, but I am not sure how to accomplish this. Any suggestions would be appreciated. Thanks. Jeff 1) Click on data series in chart, use Add trendline; in Option tab specify some units forward OR 2) Read Help about TREND and FORECAST, and SLOPE and INTERCEPT OR 3) Get crystal bal...

Let me use the Line Color icon on charts
It would speed up a lot of my work if I could use the Line Color icon on Excel charts, the same way I am able to use the Fill Color and Font Color icons. However, when I highlight any chart object, like the Plot Area, Chart Area, or a Series, the Line Color icon is disabled. -- Stuart Bratesman, Jr., MPP Muskie School of Public Service Univ. of Southern Maine Portland, Maine ---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If ...

Reference / Copy Dynamic Data
Have a worksheet listing products and prices for numerous suppliers. eg.: Supplier--Product---Price ABC-------apple-----1.00 ABC-------orange----1.20 XYZ-------brick-----3.40 XYZ-------cement----0.80 This worksheet will change often. What I would like is to reference this information on other worksheets. I would also split the info onto a worksheet for each supplier. Therefore i will have a worksheet for ABC and for XYZ, and the info in these worksheets will change as the main "index" worksheet changes. eg. Worksheet ABC contains: Product---Price apple-----1.00 orange----1.20 ...