I'm setting up ColdFusion 2018 (with Update 5) and am having an issue - it seems that "Enable Null Support" option in CF Admin does nothing.
I have some API results (from a 3rd party api) that can return null values - eg; json
{
"FirstName": "Fred",
"LastName": null,
"Email": "test#test.com"
}
When I deserializeJson( theResult ) and cfdump the struct, it has "undefined" as the value for LastName. In ColdFusion 9 (which I'm porting over to CF2018), in the example given above the value for LastName shows as "null" when doing a cfdump. My issue is that in CF2018 when I try and access this variable it throws an error
Variable LastName is undefined
It doesn't seem to make a difference if you check the box for Enable Null Support in the CF Admin or not. I've tried selecting it, un-selecting it, even restarting CF after each update.
Is this a bug? I'm using CF2018 with Update 5 (version 2018.0.05.315699). Any ideas?
"Before the ColdFusion 2018 the null value from database / JSON becomes empty string. So we couldn't differentiate NULL vs EMPTY value scenario.
To provide support for null-based implementation, new version introduce null as part of language changes in ColdFusion 2018.
https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-functions/functions-c-d/DeserializeJSON.html
Since ColdFusion 10, JSON null values become undefined.
Enable Null Support in ColdFusion 2018 is different and it's nothing to do with the null values in the JSON data handling.
Only the behavior of isNull and isDefined functions will vary with the above setting.
The isNull and isDefined functions return true for a variable with null value.
Earlier, the output of isNull function is reverse of the isDefined function output, but now it checks for a variable with value null."
Related
I'm currently building a staffing CRM in Oracle Apex for my company and we have a lead generation form that allows recruiters to add any sales leads.
Once a recruiter adds a lead the page sends an email to the assigned sales person.
Now here's my issue, I need to get APEX.MAIL to ignore any null email address fields on the form page since management wants to be able to assign up to 3 sales people to receive that lead, though they may only assign 1 or 2.
How can I make APEX.MAIL ignore the page item for the sales email if the field is null.
Right now the "To" line is p_to=> :P3_SALESMAN
How I want it to look is p_to=> :P3_SALESMAN, :P3_SALESMAN2, :P3_SALESMAN,3,
But if :P3_SALESMAN2 or :P3_SALESMAN3 are null, I want APEX.MAIL to ignore them.
Or would that even cause a problem is the field is null?
You don't indicate how you are calling APEX.MAIL...
Since APEX.MAIL is a PLSQL pkg, one suggestion is to write a wrapper PLSQL pkg that will look at the parameters you pass in (P3_SALESMAN1.2,3...) and use If Else logic to evaluate the fields as null or not and then determine whether to call the APEX.MAIL pkg.
Writing in-line PLSQL in APEX quickly becomes a maintenance and reusability headache, so you should think about always using a PLSQL stored Proc/Func to encapsulate your logic and call it from the page.
Like Joe mentioned, using stored procedure is better than writing in-line pl/sql, which I learnt the hard way.
About building the list of email addresses, I can't think of another way, but to use if-else condition, and adding email addresses to a string, if they exist and passing the final string to p_to in APEX_MAIL.
I am using an INSERT statement and want to set a field value to null when its not provided and this a little confusing.
The field (call it name) is type nvarchar in SQL Server. It was being set to name ="NULL"; in C++ in the INSERT statement and it appeared as NULL in SQL server (note shows in italic in sql server).
After I changed the INSERT query to become UNICODE compatible and adding N'NULL' per Microsoft documentation, it now appears as 'NULL' in SQL server (not shown in itatic and has extra ' around it ).
What is the different between NULL and 'NULL'? How can I set this field to real NULL when the field value is empty?
Update
From comments sections Adrew mentioned just insert NULL for name field which shows up (null) in SQL server, yet another type.
I ran the following query in SQL management studio itself to find which one is the real null.
SELECT [NAME], [CITY] FROM TABLE WHERE NAME IS NULL
This returns only those items which were set with ASCII "NULL" value. It's even more confusing.
We currently have a CRM Dynamics 4.0 system and as part of our Account Entity we have a field new_accountstatus with the following set up:
Schema
Display Name: Account Status
Name: new_accountstatus
Requirement Level: No Constraint
Searchable: Yes
Description: "V1.0"
Type
Type: Picklist
Overdiew 2. Active 3. Suspended 4.De-Energise 5.Terminated 6.Inactive
Default Value: Unassigned Value
We are contemplating upgrading and moving to CRM Online 2015 and have created an online trial and as part of the initial configuration we are trying to set up account model and the picklist with similar values and layout.
On creating a new field in CRM 2015 online I can see that the Data Type fields have completely changed. And from the available list Option Set was seemed the most relevant for my needs.
Can anyone explain to me what the Field Type of Simple and Calculated is all about? Also if I try to enter the same values as was in our old system of between 1-6 I get the message:
"The option value you specified does not use this solution's option value prefix (10,000). You should enter a number between 100,000,000 and 100,009,999"
If I enter this as 10,000,001 will this then be read as 1 from the option set as would have been the case in dynamics 4.0 picklist?
The type you need for your picklist is Option Set.
From CRM 2011 you can choose between local and global (existing) Option Set. If your picklist is used only inside account entity you can create it as local, if it is used in more than one entity (or you plan in the future that this is a possibility) you can create it as global, in order to be reused.
The difference between Simple and Calculated is a feature introduced with CRM 2015, in your case you need Simple (Calculated is in case the value becomes from a calculation, more details here: http://blogs.technet.com/b/lystavlen/archive/2014/11/20/calculated-fields-new-in-crm-2015.aspx)
Regarding the value (1-6). CRM 2011 introduced the concept of Solutions and Publishers, each Publisher can have an Option Set prefix (10000 is the value for the Default Publisher) in order to differentiate Option Set coming from different solutions.
You can still override the prefix, so you can put the values 1-6 if you prefer, the use of the prefix is suggested but not mandatory. the value 100,000,001 is different from 1, so (considering backward compatibility with external system) you should put 1 as value.
I'm doing a workflow for a SharePoint site that is taking data from another SharePoint sites list and then putting it into the new site, I have this bit working fine but I have a issue where it seems to be updating both lists due to one of the logic operations thinking that a value is not null. My question is would it be possible to use an XSLT to set a sort of Boolean that will return True when a string == Null? and if so could you give me some pointers on how to get started with this?
not ($yourString)
will return True if the string is empty, False otherwise. Not sure what "null" means in this context
The ColdFusion 10 documentation on Updating Your Database has a section on Database-related enhancements in ColdFusion 10. That page mentions that there is now support for CF_SQL_NVARCHAR among others, but with no details about them. Additionally, the cfqueryparam documentation hasn't been updated to include their existence.
The ColdFusion 9 documentation for cfqueryparam mentions that CF_SQL_VARCHAR maps to varchar in MSSQL. This is true unless the ColdFusion Administrator datasource settings has the String Format setting enabled. In which case CF_SQL_VARCHAR maps to nvarchar. This poorly documented feature is a hack which can cause performance issues within ColdFusion.
So it's great that they have introduced CF_SQL_NVARCHAR, but it would be good to understand how it works. It is simply an alias for CF_SQL_VARCHAR making it pointless? Does it always send strings as nvarchar? If so, does CF_SQL_VARCHAR always send in varchar?
I would hope that for backward compatibility's sake it is implemented as such:
If String Format is enabled CF_SQL_VARCHAR and CF_SQL_NVARCHAR both map to nvarchar.
If String Format is disabled then CF_SQL_VARCHAR maps to varchar and CF_SQL_NVARCHAR maps to nvarchar.
This would mean any pre-CF10 sites can move to CF10 and work, with the same performance considerations pre-CF10.
New sites, or sites that rewrite all queries to match CF_SQL_VARCHAR and CF_SQL_NVARCHAR with the database design will not get the performance penalty that is unavoidable pre-CF10.
Can anyone confirm if this is the case; even better if with something official?
While you are waiting for something more official, I will throw in my $0.02 ...
I did some digging and based on my observations (with an MS SQL datasource) I believe that:
CF_SQL_NVARCHAR is not just an alias for CF_SQL_VARCHAR. It maps to the newer NVARCHAR jdbc type, which lets you to handle unicode values at a more granular level.
CF_SQL_NVARCHAR values are always treated as nvarchar
The handling of CF_SQL_VARCHAR depends on the String Format setting, same as in previous versions.
CF_SQL_NVARCHAR Test/Results:
If you enable datasource logging, you can see the driver invokes the special setNString method whenever CF_SQL_NVARCHAR is used. So ultimately the value is sent to the database as nvarchar. (You can confirm this with a SQL Profiler)
// Query
SELECT ID
FROM Test
WHERE NVarcharColumn = <cfqueryparam value="#form.value#" cfsqltype="cf_sql_nvarchar">
// Log
spy(...)>> PreparedStatement[9].setNString(int parameterIndex, String value)
// Profiler
exec sp_prepexec #p1 output,N'#P1 nvarchar(4000)',N'SELECT ID
FROM Test
WHERE NVarcharColumn = #P1 ',N'Стоял он, дум великих полн'
CF_SQL_VARCHAR Test/Results:
In the case of CF_SQL_VARCHAR, it is technically flagged as varchar. However, the String Format setting ultimately controls how it is handled by the database. When the setting is enabled, it is handled as nvarchar. When it is disabled, it is treated as varchar. Again, you can verify this with a SQL Profiler.
Bottom line, everything I have seen so far says you are right on target about the implementation.
// Query
SELECT ID
FROM Test
WHERE PlainVarcharColumn = <cfqueryparam value="#form.value#" cfsqltype="cf_sql_varchar">
// Log
spy(..)>> PreparedStatement[8].setObject(int parameterIndex, Object x, int targetSqlType)
spy(..)>> parameterIndex = 1
spy(..)>> x = ????? ??, ??? ??????? ????
spy(..)>> targetSqlType = 12 (ie CF_SQL_VARCHAR)
// Profiler (Setting ENABLED)
exec sp_prepexec #p1 output,N'#P1 nvarchar(4000)',N'SELECT ID
FROM Test
WHERE PlainVarcharColumn = #P1 ',N'Стоял он, дум великих полн'
// Profiler (Setting DIS-abled)
exec sp_prepexec #p1 output,N'#P1 varchar(8000)',N'SELECT ID
FROM Test
WHERE PlainVarcharColumn = #P1 ','????? ??, ??? ??????? ????'