We have a database file we need to import a script into, the destination file has some fields using different names and possibly a custom function missing (although I can't confirm this as yet).

Having imported the script to check the number of errors, all the <Missing Field> and <Unknown> layouts are highlighted in red text and red markers on the scroll bar (nice new feature).

However, the import log was reporting some errors within calculations, but using 2EmpowerFM we couldn't find these. Finally, we established that the set variable calculations these should have been in (which would normally be disabled at this stage) were blank and no errors were displayed within the script workspace.

Is this expected behaviour of v15? I've no recollection of this happening before and missing fields or functions would normally be disabled in the calculation. I've attached an extract from the log entries This could be reliably repeated.

The first line error was caused by a missing field 'FMEmailAddress' and 'zConfig::kcCfgConstant ' field name did not match that of the destination file. After adding the missing field in the destination file and renaming the other field in the source file the calculation did import during a further attempt. We haven't got as far as the next log errors as yet.

I guess I wasn't clear enough, I was referring to the line number of the script that is displayed within the log info, not the physical line numbers. I'll post each calculation separately, copied from each variable calculation below, but these are the same as posted within the log files - each calculation is preceded by a timestamp.

The error 1205 is no ending comment. That is, it did not add a "*/" to the end of the imported calculation.

Please send in a clone of your original database file. If you want, remove all other scripts and layouts so I can replicate the importing of your script(s). This will let me know what is causing the "*/" to not be added to the end of the calculation. I have sent you a private message with instructions where to send the file.

Although we're unable to send over our complete CRM system, we have replicated the same behaviour with custom function imports and have emailed over a file for you to import custom functions from into a new empty file, which has reliably repeated the empty calculations.

Using the example file we've sent you, we've made further progress and traced part of the problem to the fact we've retained the superseded version of the calculation at the end disabled with the standard method using /* */

Your last post is a little confusing. Is this change for all three calculations or a specific calculation? If you want, send me an updated file and I'll compare the changes to understand what are the differences.

Glad to hear the file has demonstrated the problem and I'll try to be clearer on my last post.

The cict_ExtractSenderFromMessage custom function consists of:

//Descripion

Let (

<custom function contents>

)

Then below this - after Trim() - is the previous version disabled in the format:

//Superseded message

/*Let (

<old version custom function contents>

)*/

If you do the import as supplied the import will fail. However, if you remove the older disabled code below the active calculations (between /* and */) from the custom function calculation, then a subsequent import will succeed.

It seems to be the commented out calculations at the end of the overall calculation that is causing the import to fail. These CRM frameworks have evolved over 8 years, therefore many of our calculations have superseded versions retained for audit purposes.

If this still isn't clear, please let me know and I'll send over a second file to demonstrate this.

I did receive the updated file, and the new calculations are easier to understand the cause. I have sent your observations and file to our Development and Testing departments for review. When I receive any feedback, I will let you know.