Hi Jacob

<span id="_Datalead_status" class="VIEWBOX">
<select class="EDIT" size="0" name="lead_status" id="lead_status">
<option value="In Progress" selected="">In Progress</option>
<option value="Opportunity">Opportunity</option>
<option value="Closed">Closed</option>
<option value="">--None--</option>
</select>
<input type="hidden" name="_HIDDENlead_status" id="_HIDDENlead_status" value="In Progress" entrytype="21">
</span>

The value is "In Progress" in the default system.  What code is giving you issues?

Hi,

Anything that references the code as "In Progress". For instance, DefaultValue = "In Progress";

Where can I view the file that you just pasted? I'd like to look and see if my value is the same.

The value isn't in a file. It's in translations. The core CRM application is a single DLL and not a series of ASP pages. To find the entries go into Administration -> Customisation -> Translations and in the caption family, look up lead_status which will give you the entries in that drop down list.

Looks as expected I suppose. I just don't understand why attempts to reference In Progress don't work at all. 

I don't suppose you are writing code in an onChange script?  If you are then DO NOT write "In Progress" BUT INSTEAD write 'In Progress'.  See:  (+) Quotations in onChange Scripts - Sage CRM Hints, Tips and Tricks - Sage CRM - Sage City Community  

No not in on change, but good thought.

The instances I am thinking about are escalation rule SQL.

Jacob04:  Where you able to resolve this?  If you are writing triggers for an escalation rule, you will need to use 'In Progress' rather than "In Progress" as you are writing SQL script in that area.  SQL needs to be wrapped in single quotes rather than double quotes for SQL triggers.  I hope this helps!!  :-)

No. Regardless of whether we use single quotes or double quotes it doesn't work properly. I was able to use a different route to get the desired result, but referencing 'in progress' in any way doesn't work for us.

For SQL (e.g. Execute SQL Statement on Workflows/Escalation Rules, or SQL Triggers) I've never had a problem finding/Reading or writing this data. 

The only thing to watch out for if you're using 'Execute SQL Statement' on Workflow/Escalations (not sure if it has been addressed) is that the script you write in there MUST be written on a single line (even though within the box it'll word wrap) i.e. do not press enter to go onto the new line. 

We have found in the past if you include a carriage return within the box then whatever is in there never works. 

For SQL (e.g. Execute SQL Statement on Workflows/Escalation Rules, or SQL Triggers) I've never had a problem finding/Reading or writing this data. 

The only thing to watch out for if you're using 'Execute SQL Statement' on Workflow/Escalations (not sure if it has been addressed) is that the script you write in there MUST be written on a single line (even though within the box it'll word wrap) i.e. do not press enter to go onto the new line. 

We have found in the past if you include a carriage return within the box then whatever is in there never works. 

Now this seems like it could be the issue. I will try and put everything on one line. Thanks!