I am trying to replicate a column with data type char(10) to another column with datatype char(30)
While applying snapshot I get an error saying
"Field Size too large"
As per my understanding Publisher has size smaller than the Subscriber so why would this error come up?
I tried looking over the internet but could not find much help either.
The MSDN forum has pointed a similar issue with a resolution:
I had this same problem. In comparing the schema of the table in both
the publisher and subscriber, they appeared to be identical. However,
I had to drop the table on the subscriber and recreate it using a
create table script generated on the publisher. Once I did that, the
snapshot proceeded without any more errors. HTH.
Related
A new issue has cropped up this morning. I have databases that reside on SQL Server and I use Access for the front end. One of the databases which has been in use for at least 10 years now suddenly stopped working today, and I have found that the issue is one that is affecting 2 (possible more, I've not checked them all) tables.
When I open the table in access all I get is #DELETED in all the rows and colums. I have seen this behaviour before and it is usually something to do with the data type but this doesn't seem to be the case in this instance.
To troubleshoot the problem I have created a view that retrieves all the columns from the table and when this view is linked and opened in Access I have the same issue. I have found that if I link to the view without selecting a unique record identifier I can see the data without any problem. I could use this as a work-around, but clearly it is not ideal.
The SQL server version is 14.0.2037.2 and I am accessing it using SQL Server Native Client 11.0.
I have found the cause and solution. The affected tables had nvarchar fields as the primary keys. SQL Server Native Client has been deprecated for some time now and is replaced by MS OLE driver which is our mistake. The reason this problem has only reared its head now is due to an update to MS Access 365. I found this which has more details:
#DELETED when linked with ODBC
I had the same issue. This situation emerged this past weekend (5/29/2022).
This is a bug created by a 365 Office update. My update occurred 5/29/2022. The best remedy is to roll back your most-recent 365 update.
In my application, the #Deleted value appeared in all cells linked to any SQL Server table having a nvarchar field included in any unique index - it didn’t have to be a primary key. In my case, eliminating the unique attribute in any index including a nvarchar caused the problem to go away.
A new issue has cropped up this morning. I have databases that reside on SQL Server and I use Access for the front end. One of the databases which has been in use for at least 10 years now suddenly stopped working today, and I have found that the issue is one that is affecting 2 (possible more, I've not checked them all) tables.
When I open the table in access all I get is #DELETED in all the rows and colums. I have seen this behaviour before and it is usually something to do with the data type but this doesn't seem to be the case in this instance.
To troubleshoot the problem I have created a view that retrieves all the columns from the table and when this view is linked and opened in Access I have the same issue. I have found that if I link to the view without selecting a unique record identifier I can see the data without any problem. I could use this as a work-around, but clearly it is not ideal.
The SQL server version is 14.0.2037.2 and I am accessing it using SQL Server Native Client 11.0.
I have found the cause and solution. The affected tables had nvarchar fields as the primary keys. SQL Server Native Client has been deprecated for some time now and is replaced by MS OLE driver which is our mistake. The reason this problem has only reared its head now is due to an update to MS Access 365. I found this which has more details:
#DELETED when linked with ODBC
I had the same issue. This situation emerged this past weekend (5/29/2022).
This is a bug created by a 365 Office update. My update occurred 5/29/2022. The best remedy is to roll back your most-recent 365 update.
In my application, the #Deleted value appeared in all cells linked to any SQL Server table having a nvarchar field included in any unique index - it didn’t have to be a primary key. In my case, eliminating the unique attribute in any index including a nvarchar caused the problem to go away.
I have a legacy Access 97 Frontend application which utilises a SQL Server 2005 backend over a SQL Server ODBC Driver (Connection), we use the Linked Table feature on this setup.
I create, amend and link in tables on a daily basis and I am aware of the conversions that occur between the different data types.
There seems to be an issue with one table that I recently created, it has exactly the same setup and permissions as many of the other tables in the database but once I link it into Access 97 it seems to show #NAME in all columns and I also receive an 'ODBC Call Failed' error.
If I remove the Primary Key from the table and do not select a 'Unique Record Identifier' then I am able to view the data in the table but I obviously can't edit it.
There are 3 columns which are VARCHAR's and are over 255, if I reduce these columns to 255 or less I am then able to view the data in the table but if I then try to edit or delete the data I receive a new error 'The Microsoft Jet Database engine stopped the process because you and another user are attempting to change the same data at the same time' - I know this is not possible because at present I am the only one with access to the table.
In this particular table there are 146 columns, if I delete half of these then the table starts to work as it should, again I have tables that have far more columns than this and work perfectly.
Troubleshooting issues like this can be frustrating for sure.
I have found this article very helpful for my linked tables:
Optimizing Microsoft Office Access Applications Linked to SQL Server
Specifically read the section titled Supporting Concurrency Checks.
One thing you might try is adding a "timestamp" column to the table in question.
We have a column that was added to the primary database and is being replicated to a secondary database. We are now receiving the following error:
Column names in each table must be unique. Column name 'RI_SystemType' in table 'dbo.R_Information' is specified more than once. (Source: MSSQLServer, Error number: 2705)
Get help: http://help/2705
Replication is currently failing across the database and we assume that this is the cause. Any suggestions?
Ok, rookie mistake. A deployment script also created the new column in the subscriber. Of course, that's the whole point of replication so once we dropped the column from the subscriber, replication created it itself and all was well.
I am creating a server level trigger in SQL 2008 to log table creation and drops. I need to log the database that the table was created in/dropped from. First I created a column with a default value of db_name(), but this always recorded master. Next I tried using this in my insert statement:
EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]','nvarchar(max)')
This worked for a while, but suddenly it started recording master for all table creations and drops regardless of the database the table was in. All of the table drops have been done using SSMS. Does anyone know why I am seeing this behavior? Even more important, does anyone know how to log the correct database?
EDIT: I found an article which makes me think what I'm doing is incorrect. Apparently you should only capture create_table and drop_table from a database scoped trigger and not from a server_scoped trigger. I would still like to leave the question open though in case someone knows how to work around this.
HI,
You are correct, CREATE TABLE and DROP TABLE events should be recorded from within DDL Triggers that are defined at the database level.
Server Level Triggers are intended for server wide events, for example, when a Login occurs.
Here is an excellent article that may assist you in your developments.
http://www.developer.com/db/article.php/3552096
The following refence details which DDL events can be fired at either Database or Server scope.
http://msdn.microsoft.com/en-us/library/ms189871(SQL.90).aspx
Cheers,