I've got 2 databases with the exact same design and I'm receiving an error from SymmetricDS when trying to insert specific records from the Active database to the Passive.
I'm getting the following error: 'Numeric overflow in conversion of value 211 to type Tinyint'. The data has no problem going into the Active database from our application, but the replication to the Passive is raising an error. Also, I'm able to insert the same values in the passive database manually.
Is SymmetricDS doing some type of data conversion during the insert? I'm trying to understand where and why this could be happening.
Thanks,
Kaleb
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'm trying to deploy DB updates to SQL Server via Azure CI DACPAC, but I keep getting a data loss might occur error causing the deployment to fail.
Warning SQL72015: The column [dbo].[MyTable].[NonExistantField] is being dropped, data loss could occur.
Why would it try to drop a column that doesn't exist? There's no reference to this field that I can find anywhere. How do I get it to stop trying to drop the column?
Secondly, and more generally, is there a setting somewhere where I can force it to deploy even if data loss occurs? I don't care about data loss, it's irrelevant and this error forces me to update the entire database by hand.
That depends on how you are trying to deploy your updates. It will be useful to see your deployment step to get some recommendations. As an example, if you deploy through SqlPackage, you can use /p:BlockOnPossibleDataLoss='False' option.
I don't know what the exact problem was, but the solution was to go into the DB via SSMS, drop the offending table and then allow it to be recreated via deployment.
Oddly, in my first attempt I dropped the table and recreated it in SSMS and then did the deployment and it still failed with a warning about data loss.
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.
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.