Page 1 of 1

Any one tried this on a system with Visual Studio 2008?

Posted: Fri Mar 21, 2008 1:52 pm
by SteveHiner
My site used to work fine, now it's broken. The only thing I can think of that I changed between then and now is an install of Visual Studio 2008 Standard and Microsoft Expression Studio. Now the store gives me this error:
Exception Details: System.Data.SqlClient.SqlException: String or binary data would be truncated.
The statement has been terminated.

Stack Trace:

[SqlException (0x80131904): String or binary data would be truncated.
The statement has been terminated.]
System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) +925466
System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) +800118
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) +186
System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) +1932
System.Data.SqlClient.SqlDataReader.ConsumeMetaData() +31
System.Data.SqlClient.SqlDataReader.get_MetaData() +62
System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) +297
System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) +1005
System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) +132
System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) +32
System.Data.SqlClient.SqlCommand.ExecuteScalar() +137
Microsoft.Practices.EnterpriseLibrary.Data.Database.DoExecuteScalar(DbCommand command) +132
Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteScalar(DbCommand command) +140
CommerceBuilder.Reporting.PageView.Save() +1169
CommerceBuilder.Services.AbleCommerceHttpModule.a(Object A_0, EventArgs A_1) +593
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:2.0.50727.1433; ASP.NET Version:2.0.50727.1433
This happens in the store only, the admin side seems to be working OK for the most part.

Mind you, this is without doing development under VS 2008, it's just having it installed that seems to have caused this problem.

I'm totally OK with continuing development under 2005 if that's required but it's going to be tough for me to keep from installing 2008 since most of my work is as a Windows programmer.

Has anyone else seen this? Any workarounds?

I'm wondering if it's caused by a newer version of the AJAX libraries gettings installed. I'm going to check to see if I can roll back just those libraries without removing VS 2008. If that doesn't work I'll remove VS2008 entirely but I don't know if that'll even roll back changes to AJAX.

Thanks for any advice. Development on the site is frozen until I can work this out.

Posted: Sat Mar 22, 2008 9:39 am
by AbleMods
That's a tough one.

I've used VWD 2008 Express for development without problem. It's compatible, you just can't recompile certain libraries. Since I don't have full source code, it doesn't matter for my situation.

I'm running 2005 Express currently - was quicker to download after I rebuilt my XP install a few weeks ago. I'll go 2008 again soon, I like the dev environment better.

I have seen the error message you posted in my web server event log. It's been very, very rare though - like once a couple of weeks. I've never seen it in my local dev copy of AC7 nor have I seen it while running Admin or Store side when I access my site (hours at a time, daily). The event log I saw must have been from a site visitor encounter.

Wish I could provide more help, sorry. I could suggest a whole ton of things, but they'll just be darts at the wall. :(

Posted: Wed Mar 26, 2008 3:10 pm
by Logan Rhodehamel
No, this is not likely an issue with VS2008. It looks more like there is something going wrong during the saving of page view data. The error is returned by SQL Server, saying we are trying to put too much data into a field and it would have to be cut off.

There are a couple of options for getting your install back online. The quickest is probably to turn off page tracking. To do this, edit the file App_Data/ablecommerce.config and look for this:

Code: Select all

<trackPages enabled="true"
If you change enabled to false, that will disable page tracking and it should at least prevent the error you see. That's not a great long term solution.

If you feel up to investigating further, you could do the following without turning off the page tracking: Open the database. Edit the design of the table ac_PageViews. Go to all of the fields that are nvarchar(somevalue) and increase them all to nvarchar(max) if you are using SQL 2005 and nvarchar(4000) if you are using SQL 2000. Then go browse to a page that was giving you the error. After you visit the page, go to the database and copy the last record from the ac_PageViews table and provide it here (if you don't want to post you can PM it).

Then we could check the data to figure out what field we haven't made long enough, and/or whether we have a bug we can protect against.

Posted: Wed Mar 26, 2008 4:02 pm
by SteveHiner
Logan figured it out in no time. In a PM he suggested that it might be a long useragent string for my browser and look at this:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.0.3705; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.590; .NET CLR 3.5.20706; Zune 2.0; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

That's 300 characters long. I checked the DB and sure enough ac_PageViews.UserAgent is declared as nvarchar(255)

This explains the timing of the failure with the installation of VS2008 since that's likely where the second entry for the 3.5 framework came from as well as the addional entry (or two) for the 3.0 framework.

Great job Logan. It's been less than 30 minutes since I found out you replied to my post and we have a solution.

Posted: Wed Mar 26, 2008 4:12 pm
by AbleMods
That's going to affect all of the AC7 installs :(

Posted: Wed Mar 26, 2008 4:28 pm
by Logan Rhodehamel
SolunarServices wrote:That's going to affect all of the AC7 installs
If page tracking is on, yes. We did not compensate for such a long useragent string. Bug 6690 was created earlier regarding the issue.

Posted: Wed Mar 26, 2008 4:41 pm
by Logan Rhodehamel
Although I'm sitting here trying to figure out how you came to have such a long user agent string. You have many NET CLR tokens - almost like maybe you have installed several versions of the .NET 3.0 and 3.5 framework? Maybe betas? I hope this would be a rare occurrence to have such a long string, but that doesn't avoid the possibility for it to occur.

Posted: Thu Mar 27, 2008 9:18 am
by SteveHiner
I'm a .NET developer so I install a lot of .NET related stuff. I probably did install the 3.0 and 3.5 betas on this system. I also installed Silverlight 1.0, 1.1 CTP and 2.0 beta. Looks like Microsoft doesn't clean up the useragent string when you uninstall a beta framework.

Posted: Thu Mar 27, 2008 3:05 pm
by Logan Rhodehamel
SteveHiner wrote:Looks like Microsoft doesn't clean up the useragent string when you uninstall a beta framework.
That's what it seems like to me. I was trying to judge the impact and decide whether the field needs to be expanded. I think this will be a rare occurrence, so our fix will probably be to truncate the agent string ourselves and prevent the error in the sql query.

Posted: Fri Mar 28, 2008 11:04 am
by SteveHiner
I think that's a fine idea. I would totally agree since this is going to be rare and it's really not super important data anyway. The most important parts of the string are in the beginning anyway. Probably any data that could theoretically exceed the field size should be truncated just to avoid having certain users get blocked from using a site.

Posted: Fri Mar 28, 2008 11:06 am
by SteveHiner
I just noticed RC3 released. Any chance this fix made it in under the wire?

Posted: Fri Mar 28, 2008 11:17 am
by Logan Rhodehamel
SteveHiner wrote:I just noticed RC3 released. Any chance this fix made it in under the wire?
No, I am sorry, I could not do it. The move to release was already in progress by the time I nailed this one down. It became the first known issue in RC3. :(

Posted: Fri Mar 28, 2008 2:01 pm
by SteveHiner
I get credit for the first known issue? I'm so proud. 8)

No biggie, I'll just increase the field size until a fix is in place.