Loses unique keys when publish to Sharepoint

  • Thread starter Thread starter So Call Me Crazy
  • Start date Start date
S

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?!?
 
So Call Me Crazy said:
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?!?
Click to expand...


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
Click to expand...

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.
 
David W. Fenton said:
Meant to include this with my previous reply, here's a link to a
list of SharePoint limitations ...
Click to expand...
[/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.
Click to expand...

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.
 
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.
Click to expand...

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.
 
David W. Fenton said:
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.
Click to expand...


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.
 
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.
Click to expand...

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).
 
David W. Fenton said:
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).
Click to expand...


Thanks for the info, David.
 
Back
Top