In VIEW.ASCX and VIEW.ASCX.CS, should I use "Repeater1" or "rptTaskList" ???

I've seen it both ways...

Jeff

OK - we now know that

• the View.ascx control is displaying
• tasks are being created in the database
• the TaskController.GetTasks method is returning an empty list ("Tasks loaded : 0")
• since no tasks are being read the repeater control has noting to display

In looking at the data in the database Tasks table, note that the values in the ContentItemId column are all -1. Because of the way the GetTask and GetTasks stored procedures are written (with an inner join to the ContentItems table on ContentItemId) no data will be returned even though it exists in the Tasks table.

I would look closely at the SaveTask method in Components\TaskController.cs and all of the code in the components\Taxonomy\Content.cs file comparing your code with that of the source project downloaded from CodePlex.

You could also look at the ContentType table to see if a ContentType with ContentTypeName "TaskManagerTask" is being created and then after making a note of its ContentTypeId checking to see if entries with this ContentTypeId are being created in the ContentItems table for each task in the Tasks table. We will then have a better idea of where the failure to assign a ContentItemId to each entry in the Tasks table is occuring.

Note that once the coding error(s) are located and fixed only tasks created after the fix will be displayed.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

Still a no-go.

Admittedly, there was some of my "chicken-scratching" in CONTENT.CS ( I think I told you I tried to change that -1 value to a positive value), so I  replaced both it (CONTENT.CS) and TASKCONTROLLER.CS with their Codeplex counterparts, rebuilt but still with no good result.

I got to thinking a few minutes ago:  the ADD routine works, and the GETTASKS routine doesn't, so I went all the way back to SQLDATAPROVIDER.CS, noticed that the connection string for the unsuccessful one differed from that of the succesful one, changed it, rebuilt the module, tested it, again with no good result.

Jeff