Loses unique keys when publish to Sharepoint

[So Call Me Crazy]

Access 2007

It has been brought to my attention that my database is now allowing
duplicate keys. I recently published the database to SharePoint.

Database didn't behave this way prior to the publish. What is up with
this?!?

 

[Alex Dybenko]

hi,
I think you have to redefine your unique keys on Sharepoint, but could be
that it has limited support of unique keys for your needs...

--
Best regards,
___________
Alex Dybenko (MVP)
http://accessblog.net
http://www.PointLtd.com

 

[Brendan Reynolds]

Access 2007

It has been brought to my attention that my database is now allowing
duplicate keys. I recently published the database to SharePoint.

Database didn't behave this way prior to the publish. What is up with
this?!?

SharePoint does not support unique keys, except for the single unique key
that it creates automatically on the ID column.

 

[Brendan Reynolds]

SharePoint does not support unique keys, except for the single unique key
that it creates automatically on the ID column.

Meant to include this with my previous reply, here's a link to a list of
SharePoint limitations ...

http://office.microsoft.com/en-us/access/HA101314681033.aspx

 

[David W. Fenton]

Meant to include this with my previous reply, here's a link to a
list of SharePoint limitations ...

http://office.microsoft.com/en-us/access/HA101314681033.aspx

How, exactly, does MS think that kind of architecture makes
Sharepoint useful for anything at all? I am flabbergasted at this
incredibly short-sighted limitation.

I had wondered for a long time if Sharepoint was something that
might be useful with Access, but this makes it clear that it's
completely useless.

 

[Brendan Reynolds]

Meant to include this with my previous reply, here's a link to a
list of SharePoint limitations ...

[/QUOTE]

How, exactly, does MS think that kind of architecture makes
Sharepoint useful for anything at all? I am flabbergasted at this
incredibly short-sighted limitation.

I had wondered for a long time if Sharepoint was something that
might be useful with Access, but this makes it clear that it's
completely useless.

I obviously can't answer the first question.

I tried using SharePoint internally for simple shared lists, such as task
lists and phone books. It didn't take off in our company, but that was more
to do with company culture than the technical limitations of SharePoint. I
certainly would not consider it any kind of substitute for JET or SQL Server
or any RDBMS.

 

[David W. Fenton]

I tried using SharePoint internally for simple shared lists, such
as task lists and phone books. It didn't take off in our company,
but that was more to do with company culture than the technical
limitations of SharePoint. I certainly would not consider it any
kind of substitute for JET or SQL Server or any RDBMS.

It is MS's replacement for Jet replication in A2K7 for those using
ACCDB format. It's very clearly not adequate for that at all.

 

[Brendan Reynolds]

It is MS's replacement for Jet replication in A2K7 for those using
ACCDB format. It's very clearly not adequate for that at all.

As I said, I don't consider it a replacement for JET or for any RDBMS. What
Microsoft may consider it to be is an entirely different matter.

I know very little about replication. If I needed replication, I think I'd
probably investigate the possibilities of either sticking with MDB format
for the time being or moving the data to SQL Server rather than SharePoint.
I understand that SQL Server supports replication, but, as I said, it's a
subject about which I know very little.

 

[David W. Fenton]

I know very little about replication. If I needed replication, I
think I'd probably investigate the possibilities of either
sticking with MDB format for the time being or moving the data to
SQL Server rather than SharePoint. I understand that SQL Server
supports replication, but, as I said, it's a subject about which I
know very little.

SQL Server Replication is not really designed for the same scenarios
as Jet Replication, so whether or not it was more appropriate would
depend on the situation. Basically, I'd say if your back end is
already SQL Server, the choice is clear (though Jet 4 can
participate in a SQL Server 2000 replication topology;
unfortunately, that feature was removed from SQL Server 2005). But
if you're using Jet, I think there is hardly ever any advantage to
upgrading to SQL Server simply for replication purposes.

And, in fact, in most modern scenarios, I don't even consider any
form of replication necessary with the kind of apps Access is used
to develop. Any time there are fixed locations with always-on
Internet connections, hosting the Access app on Windows Terminal
Server is the obvious first choice. I am only recommending
replication these days for disconnected laptop users and for sites
that are too small to have ever required a Windows server -- it's
hard to justify the investment just for a single Access application
(unless it's crucial to the business).

 

[Brendan Reynolds]

SQL Server Replication is not really designed for the same scenarios
as Jet Replication, so whether or not it was more appropriate would
depend on the situation. Basically, I'd say if your back end is
already SQL Server, the choice is clear (though Jet 4 can
participate in a SQL Server 2000 replication topology;
unfortunately, that feature was removed from SQL Server 2005). But
if you're using Jet, I think there is hardly ever any advantage to
upgrading to SQL Server simply for replication purposes.

And, in fact, in most modern scenarios, I don't even consider any
form of replication necessary with the kind of apps Access is used
to develop. Any time there are fixed locations with always-on
Internet connections, hosting the Access app on Windows Terminal
Server is the obvious first choice. I am only recommending
replication these days for disconnected laptop users and for sites
that are too small to have ever required a Windows server -- it's
hard to justify the investment just for a single Access application
(unless it's crucial to the business).

Thanks for the info, David.