SQL error message when querying table containing one varbinary (blob) field - sql

We are using Delphi XE3 together with a TSQLDataSet and a TClientDataset to read a table into memory from SQL server 2012.
The table contains various fields, one of them a blob "varbinary(max)" where we store the content from a text file.
My problem is that we get an error message saying "connection is busy with results for another command" when we do a open on the ClientDataset.
The commandtext is a simple "select * from tablename".
This happens only if there are more than one item in the table. It also happens only if there are data in the blob field (<> NULL).
Everything work fine if we add a second varbinary field to the table. The second field does not have to contain any data.
This is driving me crazy, please help.
EDIT: As a workaround we have simply added a "dummy" varbinary field to the table. Because of this strange behavior, we have come to the conclusion that this has to be a bug in the TClientDataset component. Tried to do the same in a older version of delphi (XE2 SP3) with the same result.

Related

invalid data is getting inserted in table in sql server database

I faced a situation and also searched for it in the internet but could not be able to get any solution.
Problem
My sql server table has 15000 records. It has several columns.
Among all the records, the 'Email ID' column of one record is storing value along with an unidentified character at the beginning. (Please refer to picture attached)
What I want
I want to get rid of that character using sql query. I am using sql server 2012 version.
I tried with 'replace()' and 'patindex()'. I even tried 'stuff' function.
But, its not working. Instead, when I am fetching the data using query, it is showing that typical character.
Please help me with some ideas. If I need to do some settings in database or table, I am ready for that.
Thanks.

Access varchar limit with SQL server - Write Conflict error

I have a SQL Server 2008 database linked to an Access 2010 front end.
Some of the columns are varchar of varying lengths, from 50 to MAX. There is no default value and they can be null.
Recently, any of these columns longer than 255 started causing the write conflict error:
This record has been changed by another user since you started editing it. If you save the record, you will...
I can update other data, including varchar data, in the same row, with no problems and no errors.
This error occurs when I attempt to update the column directly from my table. It also occurs if I update the table programmatically via VBA or through a form.
It looks like this is because the column is NULL in SQL Server, but I've never seen this before with varchar columns. Is this a "feature" or a thing you just have to work around? It just started happening regardless, which is also confusing.
The leading cause of updatability problems in Office Access–linked tables is that Office Access is unable to verify whether data on the server matches with what was last retrieved by the dynaset being updated. If Office Access cannot perform this verification, it assumes that the server row has been modified or deleted by another user and it aborts the update.
There are several types of data that Office Access is unable to check reliably for matching values. These include large object types, such as text, ntext, image, and the varchar(max)(which is in your case), nvarchar(max), and varbinary(max) types.
Coming to your situation,i believe access forms may be bound to the data & produce a lot of locks on records and tables of SQL Server, those locks can prevent tables to be updated.So try to rectify Access forms which are bound to data and that are showing those updateability errors and make them work with unbound data, which allows you to read and update that unbound data to users without creating locks on the database server.

SSIS package fails with error: “Text was truncated or one or more characters had no match in the target code page.”

I recently updated an SSIS package that had been working fine and now I receive the following error:
Text was truncated or one or more characters had no match in the target code page.
The package effectively transferred data from tables in one database to a table in another database on another server. The update I made was to add another column to the transfer. The column is Char(10) in length and it is the same length on both the source and destination server. Before the data is transferred it Char(10) there as well. I've seen people reporting this error in blog posts as well as on Stack, none of what I have read has helped. One solution I read about involved using a data conversion to explicitly change the offending column, this did not help (or I misapplied the fix).
whihc version of SQl Server and SSIS are you usign?
I would say to take a look at the output and imput fields of your components. CHAR always ocupies all it's length (I mean, char(10) will always use 10 bytes) and since you are having a truncation error, it may be a start. try to increase the size of the field or cast as varchar on the query that loads the data (not as a permanet solution, just to try to isolate the problem)
Which connection you are using ADO.Net or OLEDB connection ??
Try deleting the source and destination if there are not much of changes you have to make ..Sometime the metadata cuases this problems. If this doesn't solve your problem post the screen shot of error.

"string or binary data would be truncated" when deleting row

Im using Microsoft SQL Server Management Studio Express to connect to our SQL Server 2005 (think its 2005, its version 9.000 something something). I have a table with one column that saves a lot of text. I have set the column type to text. When i have a row with lots of text in this column i cannot delete it. I get the message "string or binary data would be truncated" when i try to delete it. If i try to edit the row i get the same message. What do i do?
Considerable : i fix it by drop table and create it again, but i wanna a Solution!
Though I'm late to the party, when I review the original poster's description of the problem, it sounds like they are trying to delete the row from within the table editor interface. I just encountered this same issue with a table containing a "text" column with long text, and it appears that the issue may in fact be tied to a limitation in the editor itself. From my own investigation, it appears that you will not be able to edit a row in which a text column exceeds 4000 characters. I tested with SSMS 2008 R2.
Hopefully this will help anyone else encountering this error.
I had same problem and solved ...
after selecting top 200 row of your table, click the "Show Criteria Pane"(left side of toolbar)
now uncheck your ntext column (the column holding a big text you was talking about)
now you can delete or update any row :)
Normally this kind of error happens when you're inserting a long value into the column that can't store it. Check whether you don't have any triggers or any related logic that could do that on your behalf when you're deleting the row (e.g. for logging purposes / audit trail)
I changed my data type to nvarchar(MAX) and was able to edit and delete as I saw fit.
I discovered there was a trigger that audited changes to the record (thanks Tomas Vana), but the target audit record had a limited varchar field for the action report (varchar(1000)). It was trying to audit the deletion of records that had varchar(max) fields...duh!
I changed the action report field in the log to varchar(max) and that fixed it...
bloody obvious really...:)

MS Access error "ODBC--call failed. Invalid character value for cast specification (#0)"

Does anyone have an idea what this error means or how to solve it? I am using Access 2003 and SQL2005. It comes up when trying to add a record on a particular subform.
[Microsoft][SQL Native Client] Invalid character value for cast specification (#0)
This MS bug report describes the same message, but it is a bug in SQL Server 6.5 that has already been solved.
Solved: Apparently having no PK on the destination table was causing this, it didn't have anything to do with the subform or the query from Access. I wasn't even aware there were tables in this database without PK. Adding PK to the destination table solved it. The strange thing is the same query string that errored when executed via SQL native client, executed through SSMS with no errors. Hope this helps anyone else who has come across that strange message.
Hum, I would check the text box default on the access side. I would also bring up the linked table in design mode, and you want to check the data type that ms-access assumes here. For non supported data types ms-access will generally use a string, and sql server might be wanting something else.
So, check both the Primary key (PK) in main table, and then check the data type used (assumed) in the child table for the foreign key (FK) column. While we are at this, check your expressions used for the child/master link settings in the sub-form control (not the form, not the sub-form, but the sub-form control used in your form that links up these two tables).
Sub forms in access are sensitive if you don’t have a timestamp column in the sql server table. As mentioned check the PK and the FK data types and make sure they match up (just bring up the tables in design mode in ms-access -- you get an error message about the design mode being read only, but just continue on so you can check/view to ensure the data types match up).
So for the child table, you need a PK, a FK, and also a timestamp column (you don’t have to display the TS column in the sub-form, but you need it in the table).
Sub-forms in ms-access are sensitive and often fail if you don’t include a timestamp column in the sql table. (access uses these row version columns to determine if the data been changed).
Is one of your fields in the view calculated/built with the CAST function? In this case, you might not have the right to update/add a value for that field.
Can you execute your view in the MS SQL Studio interface and try to insert a record?
Another cause to this issue is that if you change a table name without alterting the view then the "Dependencies" of that view still remians with the table old name.
Let say I have a table 'A' and a view 'Av' which derives from 'A', and I created a new Table which will be named 'A' and I changed 'A's name to 'A_old' but I didn't executed an ALTER VIEW, so the dependencies of 'Av' still remain on 'A_old' but the view is derives from 'A' and it cuasing this Error in Access when trying to open the view as a linked table
I just spent a day battling this with an Access ADP project that was imported into a new Access 2016 ACCDB file. Initially I figured it was an issue with the application code, but I was getting this keying records directly into the table. Interestingly, the records always got written - it seemed to be the read-back that was triggering the error. Profiling the insert sql and running that from SQL Management Studio worked without any issues.
The table that was causing the problems had a GUID Primary Key. Switching that to an int column resolved the issue.
The SQL database was also littered with a few thousand extended properties which I removed before switching the PK. There was a strong suggestion from the web that these cause problems. The source of that process is documented here: Remove All SQL Extended Properties
I had this problem with Access 2016 trying to update an ODBC linked sQL Server database. Problem was a null value in field used to join the two tables. Eliminating the null value solved the problem
OK I just had this bad experience and it had nothing to do with PK or any of this stuff in my situation. The view that reported this problem in Access was created in SQL Server originally and used a CAST of DATETIME to plain old DATE to get rid of the unneeded time part. Up until today this view had caused 0 issues in Access, but started to generate heartburn just as described above.
So, I generated a Drop/Create script for the MSS view, ran it, relinked the views in Access, and the Access database was happy with the result. All my so-called tables in Access are basically views through links to MSS for reporting. I only have 1 table that actually does changes. Other than that, I do not edit through views in Access.
The message is of course useless as usual but this was my solution in my situation.
Based solely in the message you provided above, it appears that you are trying to set an invalid value to some field or parameter, etc... The message is telling you that it is trying to convert a value into an specific data type but the value is invalid for that data type... makes sense?
Please add more details so we can help you better.