1

I posted this once, but I was a bit too vague in my information, so I am trying again.

nHibernate/Fluent nHibernate seems to be truncating, or 'stripping' certain characters from strings that I submit to my database. For example, if I submit the string This\nis\na\nblock\nof\ntext\n\with\nreturns, the \n symbol represents the carriage returns. I want these to stay intact, because later, when the data is read back out, that is when it will be parsed by MarkdownDeep

However, I have noticed that the \n symbol specifically gets 'stripped' when the database does its commit. I have performed debugging all the way up to ISession.SaveOrUpdate(object) and I can confirm that the data is unaltered up to the point I can visibly follow the debugging. But then I go and look at the record in the database, and it has been stripped of this symbol.

If I use String.Replace("\n","\\n")) on the text, it will actually work right. But this does not seem like an intelligent way to go about storing everything. This means I have to continuously remember what fields may have this problem and do in-between logic.

Is there a setting I am missing in nHibernate/Fluent nHibernate that is forcing it to strip this data?

Debugged Code Path

Following the path of my code, it goes like this.

ASP.NET MVC View (textarea) -> This\nis\na\nblock\nof\ntext\n\with\nreturns

ASP.NET MVC Model (Json) -> This\nis\na\nblock\nof\ntext\n\with\nreturns

ASP.NET MVC Controller Parameter -> This\nis\na\nblock\nof\ntext\n\with\nreturns

ISession.SaveOrUpdate -> This\nis\na\nblock\nof\ntext\n\with\nreturns

Database Record -> This is a block of text with returns

So the problem is obviously happening at the ISession level.

labilbe
  • 3,501
  • 2
  • 29
  • 34
Ciel
  • 17,312
  • 21
  • 104
  • 199
  • I just tried this and I was able to insert a carriage return line feed into an nvarchar field and I was successful in inserting and reading this field without truncation. Have you verified that the SQL statement that is inserting the data is actually missing these characters? What type of field is this in your database? Which DBMS are you using? – Cole W May 20 '11 at 14:40
  • Yes, if I insert manually in SQL Management Studio it works. I am using MS-SQL. The field is an `nvarchar(1024)`. – Ciel May 20 '11 at 16:55
  • When you say insert manually do you mean you take the sql statement generated by nhibernate from the log files and put it in sms or you manually create the insert statement yourself? NHibernate generates an insert statement with the \r\n in mine that is visible in the log file. What version of NH and FNH are you using? – Cole W May 20 '11 at 17:05
  • I am using the latest version of FNH from NuGet. And I don't understand your question. If I go to SQL Management Studio and manually open the table, and type in the text, it works. If I insert the record through `ISession`, it does not work. – Ciel May 20 '11 at 17:08

2 Answers2

1

How are you actually verifying that the \n's aren't in the database record? You will not see a \n visually when you look at the record in sql management studio. It will look like a space if you just query the data. Copy and paste that data into notepad++ and show all the characters that exist in that string (I'm betting you will see the new lines).

Whenever you manually insert \n in the table view like you describe above this is not a special character. It is the actual text '\n'. Please note that '\n' != char(10). One is a special character and the other is just text.

Cole W
  • 15,123
  • 6
  • 51
  • 85
  • I feel very stupid. Yes, when output back from the database the linebreaks are intact. It never occurred to me that the database table would preserve these as rich text instead of just strings of characters. – Ciel May 25 '11 at 13:59
  • Just to add to this topic, I landed up with the same issue and couldn't figure out why SQL was not storing the carriage return and line feed characters. When running a "new query" against the db and typing "select * from tableName", copying the result column into Notepad++ doesn't contain the characters. Funny thing is, when right clicking the table in the object explorer and selecting "Select Top 1000 Rows", when copying this result set into Notepad++ the characters showed up as expected. Weird, but it seems SQL was always storing these characters – DLR Jun 29 '17 at 12:16
0

Use this add-on to log produced sql's. then you can find where is the problem. + If you are displaying the data on a web page, don't forget to use replace("\n","<br/>").

VahidN
  • 18,457
  • 8
  • 73
  • 117