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.
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?
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
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”
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.
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?
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.
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
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).
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.
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!
