Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsForm and ListForm and ListMoving Rows Between UDT ModulesMoving Rows Between UDT Modules
Previous
 
Next
New Post
1/3/2006 1:01 PM
 
This may seem odd to most people, but I figured I'd share my code, nonetheless. To work around odd customer requirements, I have to put two UDT instances on one page. They will both have the same fields, but are used for different types of items the user is tracking. For a bit of background, the reason they need this is because they have different formatting rules for the two types of data to be tracked using the UDT module. So, to get around this, we decided to add two UDT instances with the same fields. Then the customer said that they needed the ability to move a row from one UDT to the other. Now, I've seen this capability before (SourceForge Enterprise Edition uses it to move data between trackers and it's great), so I had no problem with implementing it. Unfortunately, we don't have the time to add the features in before our upcoming release, so I created a stored procedure to do a simple move.
CREATE PROCEDURE {databaseOwner}{objectQualifier}UserDefinedTable_MoveRow
    @RowId    INT,
    @ModuleId INT
AS

-- update row
UPDATE {objectQualifier}UserDefinedRows
SET    ModuleId = @ModuleId
WHERE  UserDefinedRowId = @RowId

-- update fields
UPDATE {objectQualifier}UserDefinedData
SET    UserDefinedFieldId =
(
       SELECT DISTINCT new.UserDefinedFieldId
          FROM   {objectQualifier}UserDefinedFields old,
{objectQualifier}UserDefinedFields new
          WHERE  old.FieldTitle = new.FieldTitle
            AND  old.UserDefinedFieldId =
{objectQualifier}UserDefinedData.UserDefinedFieldId
            AND  new.ModuleId = @ModuleId
        )
WHERE  UserDefinedRowId = @RowId

-- remove fields that don't exist in new module
DELETE FROM    {objectQualifier}UserDefinedData
WHERE  UserDefinedRowId = @RowId
  AND UserDefinedFieldId NOT IN
(
SELECT UserDefinedFieldId
FROM {objectQualifier}UserDefinedFields
WHERE ModuleId = @ModuleId
)

GO
If/when I actually implement this for real, I plan on implementing copy and cut options on the main view with a paste option in the action menu. Currently, the move just matches fields up by their title. That's probably the best (read: only) way to accurately do it without providing some sort of in-between screen to map data to the new module. (Hmm... now, that's an idea.)

Michael Flanakin | Microsoft Consulting Services
www.michaelflanakin.com
 
New Post
1/3/2006 1:22 PM
 

Michael,

although I see the need in your specific situation, I do not agree with your solution, as it is very specific and building it into the DNN module would result into a large amount of overhead - e.g.

  • to ensure, that there will at least remain a single field in the new target row,
  • to match renamed fields,
  • to select the target module
  • ...

Please remember, that UDT is an universal module and two UDT instances may have nothing in common - therefore IMHO such a solution might be of use for modules with fixed datastructure as Documents, Links or Announcements but not for UDT.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
1/3/2006 3:29 PM
 
I completely agree that my implementation was very specific to my situation. I think having the in-between step to map fields would be best. That screen could attempt to make assumptions on what fields to send it to, based on field title and/or datatype. There really wouldn't be any overhead in UDT, just in the process of mapping fields together, which would be trashed as soon as the transfer was complete (unless an option to save the module mapping existed for frequent moves).

I know the UDT module wasn't intended to have (but can support) multiple instances with the same structure; but I'm really trying to expand its usage beyond initial design goals. If you've ever used SourceForge's copy/cut functionality to move items between trackers, you'd know how valuable it is. For instance, let's say you have two UDT instance that track the same data. One is for active records and one is for archived data. You may want to move stuff to the archived data UDT instance when it's older than a year. This would keep the data for you, but remove it from the normal work area. That's probably the most valuable usage that I can see. Heck, that, combined with an "archive instead of delete" option could archive your records when the delete button is clicked.

I completely agree with you that this capability would be used more frequently in Documents, Links, and Announcements (just to name a few); however, that doesn't mean it wouldn't be useful for UDT.

Michael Flanakin | Microsoft Consulting Services
www.michaelflanakin.com
 
New Post
1/4/2006 11:31 AM
 

I understand your concerns, but I really dislike the solution. Implementing your idea now would us bind in honor to support that interface in future too.

Let’s imagine that there will be custom views for UDT somewhere along the way where it would be possible to filter your data using a kind of “where” clause. So you just need one state field “isArchived" which is checked for true or false. There would be no need for a second twin table, wouldn't it? Moving data between multible views is just caused editing by editing the data. I can't imagine that SourceForge implements its copy/cut functionaly by moving items between data tables.

 
New Post
1/4/2006 12:10 PM
 
Again, my quick and dirty stored procedure was simply for my immediate needs due to other limitations. I plan on fixing those limitations in time. As far as archiving goes, that was just one example. Also, you have to think about the fact that a person may want visible, hidden, and archived records. Archived records are typically moved to a different place so they don't clutter the view unneccesarily. A boolean field wouldn't handle that - well, unless you made it nullable and had a little work-around for .NET 1.1. Either way, having a second table can be done for any number of reasons. I completely understand that it's not the majority - and in fact, that the ability to copy/move rows between UDT instances is in the vast minority of things people would want to do.

SourceForge works just like UDT works. They have custom fields you can add which are all copied when you do a copy/move. All the data is copied between tracker instances, which are all kept in the same database table, just like UDT. All that really needs to happen with a move is to change the module ID on the row and field IDs of the data and remove unnecessary data.

I only spent 5 mins on deciding how to move rows between UDT instances and actually writing the stored procedure, so I wouldn't be opposed to any other implementations. Honestly, my feelings wouldn't be hurt if it wasn't ever implemented I was just simply posting my solution for my problem just in case someone else could use it.

Michael Flanakin | Microsoft Consulting Services
www.michaelflanakin.com
 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsForm and ListForm and ListMoving Rows Between UDT ModulesMoving Rows Between UDT Modules


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out