Error 3409 when trying to link to SQL Server table

Hi,
We are using SQL Server 2000 (latest SP) on Windows Server 2003.
Recently we made database changes where we deleted a number of columns from
the highest level table in our database hierarchy (every other table is
either a child or grandchild of this table).
Since we did that we can no linker establish links from Access 2003 to this
table. When we try, we get the following error message:
Invalid field definition <STAMP1> in definition of index or relationship.
(Error 3409)
STAMP1 is our Primary Key field.
None of the fields we deleted were index fields, and none were keys. We have
been racking our brains trying to find the issue but to no avail. Please
help. Thank you.A long time ago with access 2003 I ran into a similar problem. What I
had to do was to go into the Access application, delete all of the
linked tables, check the queries/reports, and finally relink the
tables given the names used in the queries and reports. After a
meticulous going over, it worked. I know from using it though, it
seems like everytime you make a change to the strcture (an index, PK,
etc) you have to relink the tables from Access.
Let me know what you find out.
-Sean
On Feb 29, 1:09=A0pm, Berean <Ber...@.discussions.microsoft.com> wrote:
> Hi,
> We are using SQL Server 2000 (latest SP) on Windows Server 2003.
> Recently we made database changes where we deleted a number of columns fro=m
> the highest level table in our database hierarchy (every other table is
> either a child or grandchild of this table).
> Since we did that we can no linker establish links from Access 2003 to thi=s
> table. When we try, we get the following error message:
> Invalid field definition <STAMP1> in definition of index or relationship.
> (Error 3409)
> STAMP1 is our Primary Key field.
> None of the fields we deleted were index fields, and none were keys. We ha=ve
> been racking our brains trying to find the issue but to no avail. Please
> help. Thank you.|||Hi Sean,
The effect is happening when anyone tries to link to the SQL Server table,
whether the link was preexisting or not. Even new link attempts generate the
same error.
We have tried rebuilding the indexes on SQL Server and even tried making a
dummy table with the data but no indexes. We could link to the dummy but not
to the one with indexes.
"Berean" wrote:
> Hi,
> We are using SQL Server 2000 (latest SP) on Windows Server 2003.
> Recently we made database changes where we deleted a number of columns from
> the highest level table in our database hierarchy (every other table is
> either a child or grandchild of this table).
> Since we did that we can no linker establish links from Access 2003 to this
> table. When we try, we get the following error message:
> Invalid field definition <STAMP1> in definition of index or relationship.
> (Error 3409)
> STAMP1 is our Primary Key field.
> None of the fields we deleted were index fields, and none were keys. We have
> been racking our brains trying to find the issue but to no avail. Please
> help. Thank you.|||We recently tried rebuilding and renaming all indexes, and are receiving the
same error.
To restate, this is occuring whether we open existing links to Access or try
to build new ones, and only happens on the table we dropped some columns
from.
"Berean" wrote:
> Hi Sean,
> The effect is happening when anyone tries to link to the SQL Server table,
> whether the link was preexisting or not. Even new link attempts generate the
> same error.
> We have tried rebuilding the indexes on SQL Server and even tried making a
> dummy table with the data but no indexes. We could link to the dummy but not
> to the one with indexes.
> "Berean" wrote:
> > Hi,
> >
> > We are using SQL Server 2000 (latest SP) on Windows Server 2003.
> >
> > Recently we made database changes where we deleted a number of columns from
> > the highest level table in our database hierarchy (every other table is
> > either a child or grandchild of this table).
> >
> > Since we did that we can no linker establish links from Access 2003 to this
> > table. When we try, we get the following error message:
> >
> > Invalid field definition <STAMP1> in definition of index or relationship.
> > (Error 3409)
> >
> > STAMP1 is our Primary Key field.
> >
> > None of the fields we deleted were index fields, and none were keys. We have
> > been racking our brains trying to find the issue but to no avail. Please
> > help. Thank you.

Error 3409 when trying to link to SQL Server table

Hi,
We are using SQL Server 2000 (latest SP) on Windows Server 2003.
Recently we made database changes where we deleted a number of columns from
the highest level table in our database hierarchy (every other table is
either a child or grandchild of this table).
Since we did that we can no linker establish links from Access 2003 to this
table. When we try, we get the following error message:
Invalid field definition <STAMP1> in definition of index or relationship.
(Error 3409)
STAMP1 is our Primary Key field.
None of the fields we deleted were index fields, and none were keys. We have
been racking our brains trying to find the issue but to no avail. Please
help. Thank you.
A long time ago with access 2003 I ran into a similar problem. What I
had to do was to go into the Access application, delete all of the
linked tables, check the queries/reports, and finally relink the
tables given the names used in the queries and reports. After a
meticulous going over, it worked. I know from using it though, it
seems like everytime you make a change to the strcture (an index, PK,
etc) you have to relink the tables from Access.
Let me know what you find out.
-Sean
On Feb 29, 1:09Xpm, Berean <Ber...@.discussions.microsoft.com> wrote:
> Hi,
> We are using SQL Server 2000 (latest SP) on Windows Server 2003.
> Recently we made database changes where we deleted a number of columns from
> the highest level table in our database hierarchy (every other table is
> either a child or grandchild of this table).
> Since we did that we can no linker establish links from Access 2003 to this
> table. When we try, we get the following error message:
> Invalid field definition <STAMP1> in definition of index or relationship.
> (Error 3409)
> STAMP1 is our Primary Key field.
> None of the fields we deleted were index fields, and none were keys. We have
> been racking our brains trying to find the issue but to no avail. Please
> help. Thank you.
|||Hi Sean,
The effect is happening when anyone tries to link to the SQL Server table,
whether the link was preexisting or not. Even new link attempts generate the
same error.
We have tried rebuilding the indexes on SQL Server and even tried making a
dummy table with the data but no indexes. We could link to the dummy but not
to the one with indexes.
"Berean" wrote:

> Hi,
> We are using SQL Server 2000 (latest SP) on Windows Server 2003.
> Recently we made database changes where we deleted a number of columns from
> the highest level table in our database hierarchy (every other table is
> either a child or grandchild of this table).
> Since we did that we can no linker establish links from Access 2003 to this
> table. When we try, we get the following error message:
> Invalid field definition <STAMP1> in definition of index or relationship.
> (Error 3409)
> STAMP1 is our Primary Key field.
> None of the fields we deleted were index fields, and none were keys. We have
> been racking our brains trying to find the issue but to no avail. Please
> help. Thank you.
|||We recently tried rebuilding and renaming all indexes, and are receiving the
same error.
To restate, this is occuring whether we open existing links to Access or try
to build new ones, and only happens on the table we dropped some columns
from.
"Berean" wrote:
[vbcol=seagreen]
> Hi Sean,
> The effect is happening when anyone tries to link to the SQL Server table,
> whether the link was preexisting or not. Even new link attempts generate the
> same error.
> We have tried rebuilding the indexes on SQL Server and even tried making a
> dummy table with the data but no indexes. We could link to the dummy but not
> to the one with indexes.
> "Berean" wrote:

Error 20068, Article Column Max 256

I'm trying to replicate a table that now has more than 256 columns. SQL2000
chokes when creating replication with error 20068, stating that the maximum
number of columns allowed for an article is 256.
The workarounds I am aware of involve creating two tables and using views to
abstract this change from the front end application. There is no way my
client will pay for a change as drastic as this with the only benifit is that
replication will now be allowed to work.
I have two questions:
a. Is there a better workaround?
b. Does SQL2005 solve this issue (I might be better able to sell my client
on an upgrade)?
partitioning the table as you describe is the standard workaround in SQL
Serever 2000.
In SQL Server 2005, for merge the max no of columns is 246. For
transactional and snapshot it is 1000 (995 with Oracle).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||If the application using this table uses a stored procedure to make the
updates you may be able to replicate the execution of the stored procedure -
however there is the same procedure limit. Another option is to use a
trigger to write to two "audit" tables and replicate these audit tables to
the subscriber where they in turn assemble the final row.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"dtaylo75" <dtaylo75@.discussions.microsoft.com> wrote in message
news:EE67681F-C2FE-489B-88B1-1A69F719DE6D@.microsoft.com...
> I'm trying to replicate a table that now has more than 256 columns.
> SQL2000
> chokes when creating replication with error 20068, stating that the
> maximum
> number of columns allowed for an article is 256.
> The workarounds I am aware of involve creating two tables and using views
> to
> abstract this change from the front end application. There is no way my
> client will pay for a change as drastic as this with the only benifit is
> that
> replication will now be allowed to work.
> I have two questions:
> a. Is there a better workaround?
> b. Does SQL2005 solve this issue (I might be better able to sell my client
> on an upgrade)?