SeedCode Support Forum

I've just started setting up DayBack for use with Tasks (those are my events) that each have a Crew assigned. The Crews are created elsewhere (a foreman and some laborers), and it is the CrewID that is assigned to each Task. Basically, users should only be able to change the date and crew in Calendar mode. I'm using a custom layout instead of the Event popover and that helps with that level of control. Dates are changed by dragging in the WV or in the custom layout fine. Crews are changed in the custom layout (popup value list hiding IDs) fine. But dragging an event from one Resource to another Resource in the Resource WV is not working.

Here's the setup:
Source no1 is set to the TASK table. Resource is mapped to ID_Crew (foreign key in TASK for its crew)
Related source no1 is set to the CREW table. id is mapped to the CrewID and name is mapped to the CrewName.
Load Resources script has been modified to set $$sc_ResourceList using a List calc and the Crew Names show up fine as Resource column headers.
Create Edit Delete Event script has been modified to use ExecuteSQL to get the CrewID and set the TASK::ID_Crew field.

When I drag a Task from one Resource to another, I can watch everything in the debugger and monitor the utility window (which is displaying temporarily within normal view). I can see the variables are OK and the foreign key is getting set as I would expect it. But, towards the very end, right after exporting the CalendarInterface::ExportGlob (in Export Data To Temp Directory script), I see my Task flop back to its original Resource.

How can I make sure dragging in the Resource view works? TIA,

debi

Hi Debi. The Resource field is set up to use the actual value(s) entered into the field, so you should set up your value list to return the crew names (not CrewID). That same value list is also used to populate the column headers on the Resource view. If you drag a task from one column to another, DayBack will substitute the resource name from the original column with the resource name of the target column. The "Related Source No 1" layout is for contacts, not resources. HTH -Jeff

Thanks for the reply, Jeff, but I'm still confused. I've gone back over this, and am trying to follow the instructions here (http://www.seedcode.com/pmwiki/index.ph ... .Resources), both of these sections: What if I have a table I'd like to use for resources?" and "What if I'm using the ID instead of the resource name to link resources and events?"

First of all, I've eliminated any mapping on the "Related_Source No 1" layout, as we're not using contacts at all (at least right now).

The Task (events) table still has Crew ID, as we're using that in our primary file with a "two-field" popup value list to assign a Crew to a Task. I've also added a Resource field to my Tasks table so it is just a local field in the Task table. It is auto-entering the Crew Name based on the Crew ID for the Task, and is "none" if the Crew ID is empty. It is this text field that is mapped to "Resource" on the Source No 1 layout.

Per the web instructions, I'm generating a custom "$$sc_ResourceList" using a SQL statement listing the Crew Names and appending "none." I also altered the Resources value list in DayBack to use the two-field value list I use in the primary file, as I have a custom DayBack Event layout being used in lieu of the web viewer popup when clicking on a calendar event.

So far, all of that is working fine. I can change resources in the primary file or in the layout popup in Dayback without any trouble, and changing them in one location changes them in the other. When I switch to the Resource view, I am seeing all the correct columns and the correct Tasks under each.

The problem I am having is that dragging events in the Resource view, in order to assign a new Resource to the task, is not working. Per the web instructions, I've modified the "Create Edit Delete Event" script. Under the Resource section, after Set Field by Name, I've added these steps:
* Set variable $crew_name (uses the value pushed into the previous step)
* Set variable $crew_id (uses SQL to look up the id for $crew_name)
* Set Field TASK::Crew_ID to $crew_id
(have also tried a Commit afterwards)
and I've done this both for the $sc__CSVOutput = "yes" section and the Else section.

Watching this in the debugger, everything looks OK until right near the end. When the "Refresh Calendar Event" script runs "Export Data to Temp Directory" script using the sc_watcher.txt and $sc_QueryID parameters, and that script runs the Export Field Contents step at the end, the event jumps back to its original Resource.

The oddest thing is that the data is accurate! If I pop the event in DayBack, I can see that the Resource has changed, and I can see that in the primary file as well: both the key and the Resource text field are correct. But the Resource view is not correct, in that the task is returned to its original column.

I feel so close, but there must be something I'm doing wrong. Do you know what it is?

TIA,
debi

Jeff,

I know it’s been a while, but I just wanted to come back here and acknowledge your back-channel review of this issue. I’ve been meaning to start with a fresh copy of your newest build, following the few changes I made per my understanding of the documentation for modifications as well as your suggestions, and provide an update. Unfortunately, the more time passes, the less likely I am to revisit this issue. If it rears its head again, I will let you know.

Thanks again,
debi

Sounds good, Debi. Keep us posted. I'll paste my latest backchannel response to you here for the benefit of anyone else who might encounter a similar situation:

I think the problem is that the value in the Resource field (the crew id) is not among the values in the Resources value list, which you are populating with the crew names. That "What if I'm using the ID instead of the resource name" article describes how you can "add" the id to the Resource field (multiple return-delimited values), but I think you're replacing it. Either way, the Resources value list should be your crew names, not ids.