Now, ok... I can understand the fact that there HAS to be some sort of limit imposed on Item Name length. What eludes me though, is the "100 character" limit, when the database looks like this: I looked around, and this length isn't configurable anywhere I can locate (in Sitecore 5.1.x atleast).
An item name can not be more than 100 characters in length at Sitecore.Data.Items.ItemUtil.AssertItemName(String name) at Sitecore.Data.DataManager.AssertItemName(String itemName) at Sitecore.Data.DataManager.AddFromMaster(String itemName, ID itemID, ID masterID, Item parent) at Sitecore.Data.Items.Item.Add(String name, MasterID masterID)
Tuesday, May 23, 2006
Thursday, April 06, 2006
- Fixed: Events for DataList controls (such as DataGrid, Repeater, etc.) do not work with Sitecore. Didn't encounter this one myself.
- Fixed: Performance Counters throw access denied errors on Windows 2000 Server and Windows 2003(IIS 5 /Isolated mode) when someone tries to access the back-end. Mentioned this one, after spending a couple of hours trying to figure out what was going on. Excellent that this is now fixed ;-)
Other than that, it looks to be a minor bugfix release with no other major changes.
Monday, March 06, 2006
Wednesday, February 15, 2006
Thursday, January 19, 2006
Important Note: it is not possible to upgrade from version 188.8.131.52 to 184.108.40.206. Nevertheless, you can use the common Sitecore package to transfer the data from 220.127.116.11 to a clear 18.104.22.168 installation.Now this just makes very little sense to me. Especially considering the changes the patch implements (according to the change log):
- UI - Content editor - Bug - clicking Save multiple times results in all html fields being wiped out
- UI - HTML editor - Bug - Saving link and maps in HTML editor is incorrect
- UI - Content editor - Bug - onClick attribute is thrown out from html field when saving
Apparently, all of it Sheer UI fixes. No mention of the IDTable bug that surfaced in 22.214.171.124, so guess we're gonna be patient for a while longer on that one ;-)
Now I worry though... if upgrading from 126.96.36.199 to 188.8.131.52 isn't possible, and only difference between 184.108.40.206 and 220.127.116.11 is just a series of Sheer UI changes - what about the upgrade from 18.104.22.168 to 22.214.171.124 that I performed recently?
Anyhow. Gonna test out the 126.96.36.199, and take a closer look at things.
Thursday, January 12, 2006
We rely heavily on the use of external data sources for this project (well any project), and the 188.8.131.52 release offered some very nifty options in this regard - specifically the IDTable class. But unfortunately, not everything regarding external datasources and IDTable mapping was quite "in place" in 184.108.40.206. We experienced issues of what looked to be endless recursion, template editor hanging and similar. To start with something positive - this is all fixed in 220.127.116.11 :-) Or atleast, I've experienced no such issues - and I used to get them more or less all the time.
On the downside - IDTable is broken at this time. Apparently part of the solution to the above problems was, to introduce a new layer of ID mapping (atleast that's the only answer I can come up with) - meaning that any external object would be mapped ONCE against Sitecore in general - then a multitude of times for each Shadow Copy made of the object. To do this, a new field "ItemID" was introduced in the Master database on the IDTable table. All of this is probably good and well, except noone can really have been putting this through extensive testing ;-) Because the IDTable code hasn't changed. It still works on the 18.104.22.168 fields ID, Prefix, Key, ParentID and CustomData. And since the new column ItemID doesn't allow nulls, you're going to run into an SqlException whenever you attempt to add new mappings using IDTable.Add(). Fortunately, there's a few options one can do to fix this. An obvious choice is to remove the column entirely. As far as I can tell, there's no place in Sitecore that uses this field yet - this option was also suggested from Sitecore Support.
Alternatively you could implement a default value for the field - or simply set it to allow NULLS. As I don't fully know what functionality this field is going to be supporting in the future, I cannot predict which of these 3 solutions will be best in the long run. I expect this issue to be resolved soon enough, anyhow :-) We're using SqlServer databases by the way, I don't know if the Firebird implementation has similar issues.