Property names containing aA will make saving of the type to fail

bug
#1

As the topic title say - if you use a propertyname containing a lowercase a followed by an uppercased A, any editing of data on a type will fail.

You can create an instance of the type, and the initial property values will be saved. But trying to edit the instance and any changes you make to any of the instances properties will not be saved. No error is displayed though.

Here is the property that triggered the error:

<cfproperty ftSeq="1503" ftWizardStep="Call to action" ftFieldset="Call to action"
			name="ctaAction" type="string" required="true" default=""
			ftlabel="Handling" />

When starting to understand that this was the property that created the problem we first thought it was the word Action as part of the name that caused the problems.

But after testing a lot of variations of the name, the conclusion is that a lowercase a followed by an uppercased A is what creates the problem.

#2

I am not an expert, but I can’t see aA being an issue in property names. I would imagine it’s a coincidence and there’s something else afoot here.

Are you able to share more of the type in question? Is possible, could you also share some details about your setup like FarCry version, database type and version, ACF or Lucee and corresponding version?

#3

My initial guess would be that the issue is related to array properties.

Possibly some code that is looking at the property name and not its type.

Chris.

#4

We did some pretty heavy debugging and testing. Isolated the issue to this one property - also with other names with the same letter combination. Same result. Changing the name to something else - even just changing the lowercase a to an uppercase A would resolve the problem.

FarCry version 7.2.4 - Windows server with IIS and CF 11 - MSSQL server 2012

#5

Our guess was in the same direction, but we were not able to find where in the core code the problem could be located.

#6

We did some more testing, looks like the bug only is affected on wizards, this does not work:

<cfcomponent name="amTestType.cfc" displayname="amTestType.cfc" extends="farcry.core.packages.types.types" bFriendly="false">

	<cfproperty ftSeq="1" ftWizardStep="Step 1" ftFieldset="General"
				name="title" type="string" required="true" default=""
				ftLabel="Title" ftValidation="required" />
	
	<cfproperty ftSeq="2" ftWizardStep="Step 2" ftFieldset="General"
				name="ctaAction" type="string" required="true" default=""
				ftLabel="Label name" ftValidation="required" />

</cfcomponent>

While this does work:

<cfcomponent name="amTestType.cfc" displayname="amTestType.cfc" extends="farcry.core.packages.types.types" bFriendly="false">

	<cfproperty ftSeq="1" ftFieldset="General"
				name="title" type="string" required="true" default=""
				ftLabel="Title" ftValidation="required" />
	
	<cfproperty ftSeq="2" ftFieldset="General"
				name="ctaAction" type="string" required="true" default=""
				ftLabel="Label name" ftValidation="required" />

</cfcomponent>
#7

Have you tried defining the ftType? e.g.

<cfproperty ftSeq="2" ftWizardStep="Step 2" ftFieldset="General" name="ctaAction" type="string" required="true" default="" ftType="string" ftLabel="Label name" ftValidation="required" />

Also, worth checking that the property is set up correctly within FarCry stCOAPI, use the scope dump .
stcoapi STRUCT > amTestType STRUCT > stProps STRUCT > ctaAction STRUCT > METADATA STRUCT > ftType STRING >
It should be “string”

Chris

#8

If ftType not defined it will default to the type attribute.

#9

We have narrowed it down to MSSQL (2012)

If we have “wrong” casing for any column that has some type of double a (aA, AA, Aa) it will fail. Wrong casing for columns that doesn’t contain double aa works.

Correct casing:

Wrong casing

Wrong casing for objectID works :

#10

Whoa, that’s a super strange bug…

Is there anything we might need to fix in dmWizard that is partially causing the problem, or were you able to fix it by dropping and recreating the column?

#11

Haha, yes this is very strange. :confused:

We can drop the colum, but then we need to use only uppercase letters in the property name.

I have not debugged the SQL generated from ft:form’s and wiz:wizard’s yet. But i guess wiz:wizard’s uppercases the propertyname’s, and ft:form keeps the property name casing. I will do some testing/logging and post it here.

#12

Can you right click on the table in Management Studio and generate the SQL used to create it, and paste it here?

#13

Sure :slightly_smiling:

USE [db_name]
GO

/****** Object:  Table [dbo].[amTestType]    Script Date: 24.02.2016 21:48:58 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[amTestType](
	[ownedby] [nvarchar](250) NULL,
	[createdby] [nvarchar](250) NOT NULL,
	[lastupdatedby] [nvarchar](250) NOT NULL,
	[datetimecreated] [datetime] NOT NULL,
	[label] [nvarchar](250) NULL,
	[datetimelastupdated] [datetime] NOT NULL,
	[lockedBy] [nvarchar](250) NULL,
	[locked] [bit] NOT NULL,
	[title] [nvarchar](250) NOT NULL,
	[ObjectID] [nvarchar](50) NOT NULL,
	[ctaAction] [nvarchar](250) NOT NULL,
PRIMARY KEY CLUSTERED 
(
	[ObjectID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT (NULL) FOR [ownedby]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ('') FOR [createdby]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ('') FOR [lastupdatedby]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ('2216-02-24 15:42:52') FOR [datetimecreated]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT (NULL) FOR [label]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ('2216-02-24 15:42:52') FOR [datetimelastupdated]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT (NULL) FOR [lockedBy]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ((0)) FOR [locked]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ('') FOR [title]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ('') FOR [ObjectID]
GO

ALTER TABLE [dbo].[amTestType] ADD  DEFAULT ('') FOR [ctaAction]
GO
#14

Position 5 with ftWizardStep attributes - wrong case: CTAACTION
Position 10 without ftWizardStep attributes - correct case: ctaAction

#15

Can you right click on your database in Management Studio, select Properties, and then see what Collation the database is set to use?

I previously thought that collation only affected the data that was stored, but from searching about the issue I’m seeing references that say using a Case Sensitive collation (i.e. CS instead of CI) may also affect schema objects (table names and column names). I can’t find anything specific in the MS docs yet…

If you happen to be using a Case Sensitive collation (CS) but were unaware of it, or didn’t choose to use it specifically, then you may run into other issues building your app. It’s possible that you might need to consider re-creating the database using a Case Insensitive collation (or run a script to convert it).

#16

I actually checked this setting earlier, but forgot to mention it here, we are using CI collation

In my example above it worked with uppercased objectID

#17

Ok cool. The next thing to check is the column itself, SQL Server lets you have column level collation settings; expand the table, Columns, then right click on the column name and choose Properties and see what the collation is set to.

#18

Didn’t know about that, but it’s CI also

#19

Hmmm, I was expecting that one might case sensitive… I think trying to fix dmWizard-related updates might be the only easy way forward for now. I don’t have time today but I can try to debug it tomorrow!

1 Like