[FIXED] Inconsistant stripping of table column names

Posts   
 
    
swallace
User
Posts: 648
Joined: 18-Aug-2003
# Posted on: 18-Sep-2003 15:42:19   

Not sure if this is by design, but it seems inconsistent.

When the ConstantsEnums.cs file is created, a table with this design:

CREATE TABLE [dbo].[Pyrl - W2 Work] (
    [EMP ID] [nvarchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [1] [money] NULL ,
    [2] [money] NULL ,
    [3] [money] NULL ,
    [4] [money] NULL ,
    [5] [money] NULL ,
    [6] [money] NULL ,
    [7] [money] NULL ,
    [8] [money] NULL ,
    [9] [money] NULL ,
    [10] [money] NULL ,
    [11] [money] NULL ,
    [12] [money] NULL ,
    [13] [money] NULL ,
    [13b] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [14] [money] NULL ,
    [15] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [15CK1] [bit] NOT NULL ,
    [15CK2] [bit] NOT NULL ,
    [15CK3] [bit] NOT NULL ,
    [15CK4] [bit] NOT NULL ,
    [15CK5] [bit] NOT NULL ,
    [15CK6] [bit] NOT NULL ,
    [15CK7] [bit] NOT NULL ,
    [17] [money] NULL ,
    [18] [money] NULL ,
    [20] [money] NULL ,
    [21] [money] NULL ,
    [EMP Name] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [SS#] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [EMP Address 1] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [EMP Address 2] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [EMP City] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [EMP State] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [EMP Postal] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Emp Country] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Control Number] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Void] [bit] NOT NULL 
) ON [PRIMARY]

creates enums of this:

    public enum PyrlW2WorkFieldIndex:int
    {
        EMPID,
        _,
        _,
        _,
        _,
        _,
        _,
        _,
        _,
        _,
        _1,
        _1,
        _1,
        _1,
        _13,
        _1,
        _1,
        _15CK,
        _15CK,
        _15CK,
        _15CK,
        _15CK,
        _15CK,
        _15CK,
        _1,
        _1,
        _2,
        _2,
        EMPName,
        SS,
        EMPAddress1,
        EMPAddress2,
        EMPCity,
        EMPState,
        EMPPostal,
        EmpCountry,
        ControlNumber,
        Void,
        AmountOfFields
    }

Note that the leading numbers are stripped when the field only has a number as the field name, but not so in the instance of 15CK1 or 15CKx.

Unfortunatly, I cannot control these tables, they are legacy and not to be changed. (What were they thinking, creating a column named "void"????)

I can use the Entity Properties to change things like the void column, but there are dozens of tables with plenty of columns with the number issue.

Is this a by design thing? If so, I'm still not sure it's working as expected.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39866
Joined: 17-Aug-2003
# Posted on: 18-Sep-2003 16:30:45   

It is not about stripping, it's about creating field names that work as properties for example. The tool should prefix a number with a '_'. I'll look into this to check if the routine really works with a columnname with just decimal digits. simple_smile

(indeed nice design simple_smile , I feel your pain...)

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39866
Joined: 17-Aug-2003
# Posted on: 18-Sep-2003 18:01:40   

Fixed in the install which will be released today (september 18th). I'll upload this install later tonight. (it only went wrong when there was a single digit number. This is now corrected). You have to live with the '_' I'm afraid...

Frans Bouma | Lead developer LLBLGen Pro
swallace
User
Posts: 648
Joined: 18-Aug-2003
# Posted on: 18-Sep-2003 18:42:25   

Sounds good. Thanks for the quick fix.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39866
Joined: 17-Aug-2003
# Posted on: 18-Sep-2003 19:10:28   

No problem, it was a silly counter not being increased flushed

Frans Bouma | Lead developer LLBLGen Pro