Hi John,

By calling the stored procedure itself you are utilizing a level that is "too low" and will result in the sorts of headaches you are experiencing.  As an alternative, I strongly recommend taking advantage of the higher-level business classes to interact with the framework.

In this case, to create a new folder, utilize the FileSystemUtils.AddFolder static method.  For example:

        FileSystemUtils.AddFolder(PortalController.GetCurrentPortalSettings(), "myParentFolder", "myNewFolderName")

To create secured or database-secured folders, there is an overload accepting an additional integer.  Use the StorageLocationTypes enumeration to select one of these alternative locations.

Hope this helps!

Brandon 

 Hi John,

The relevant code is located in Common/Utilities/FileSystemUtilities.vb and Services/FileSystem/FolderController.  The FileSystemUtilities class essentially delegates control to the controller (except for some default permission configuration), so look there to see the bulk of the action.

It does not appear that the controller class is doing anything particularly noteworthy, so it's not impossible that you will be able to reach a satisfactory solution through the stored procedures.  However, these may change at any time in the future making any direct-access solution potentially very brittle.  You may also have some caching issues that make a satisfactory solution possible.

If I were in your shoes, I would open up the Folders table in my database after creating a single folder via the SP and look to see if anything stands out as being especially "wrong" about the data placed therein.  Are the slashes in the correct place?  Is the createdByUserId valid?  Does the path end with a terminating slash?

Because you are interacting with the framework in a highly unusual manner, you'll likely be on your own for the bulk of the debugging work, but hopefully that might get you started.  Best of luck!

Brandon