Fares database import

[BlueFox]

A couple of years ago I installed fares datbase on my PC using Soil's code and instructions - http://www.railforums.co.uk/showthread.php?t=81177

I've now got a new PC and want to install it again with the latest fares, but I'm getting an error message when I try to import the data.

Anyone have any ideas how to fix this?

I'm running it on Windows 10 64 bit and an up to date version on MS SQL Server 2012.


I've attached an image of the error message.

 

[najaB]

Reading that error message literally: you've got two records in the railcards table with the same key. Have a look at the data (I'm assuming it's an import) and see if it's corrupted.

 

[RJ]

Open the "create database" file in SQL Explorer and change the parameter under the relevant section (railcards) to ignore duplicate key values. Save the file, delete the "trains" database created in SQL then try again.

Not sure if it breaks anything important, but it stops that error message coming up.

 

[BlueFox]

Open the "create database" file in SQL Explorer and change the parameter under the relevant section (railcards) to ignore duplicate key values. Save the file, delete the "trains" database created in SQL then try again.

That worked, thanks.

 

[soil]

according to the spec on the atoc website the primary key is the railcard code AND end date. in my database I made the code the primary key.

looking at the data (.rlc file) there are a few multiple entries

e.g.,

CRC260120161311201418112016ACAMBRIANRAILCARD    NYNNCRCY00800100100100100000800100000000000500000000001200        YZNN021000000
CRC311229992701201618112016ACAMBRIANRAILCARD    NYNNCRCY00800100100100100000800100000000000500000000001200        YZNN021000000

I can't actually see any difference between the two, but in theory I guess they want to be able to change railcards from certain dates. so you could modify the key in the sql file

CONSTRAINT [PK_Railcards_1] PRIMARY KEY CLUSTERED
(

 ASC,
        [EndDate] ASC
)

or you could delete the duplicate entries manually.

Or you could indeed delete the primary key entirely, the railcards table isn't actually used anywhere.

 

[RJ]

That worked, thanks.

No worries. There are so many fares revealed in there to be set at rates much lower than they should be - but are very unlikely to be picked up by barriers, revenue staff or even split ticketing websites. It's an incredibly useful tool to have if you know what to look for!

 

[RJ]

according to the spec on the atoc website the primary key is the railcard code AND end date. in my database I made the code the primary key.

looking at the data (.rlc file) there are a few multiple entries

e.g.,

CRC260120161311201418112016ACAMBRIANRAILCARD    NYNNCRCY00800100100100100000800100000000000500000000001200        YZNN021000000
CRC311229992701201618112016ACAMBRIANRAILCARD    NYNNCRCY00800100100100100000800100000000000500000000001200        YZNN021000000

I can't actually see any difference between the two, but in theory I guess they want to be able to change railcards from certain dates. so you could modify the key in the sql file

CONSTRAINT [PK_Railcards_1] PRIMARY KEY CLUSTERED
(

 ASC,
        [EndDate] ASC
)

or you could delete the duplicate entries manually.

Or you could indeed delete the primary key entirely, the railcards table isn't actually used anywhere.[/QUOTE]

In that case it looks like the validity dates - maybe a very subtle update to the validity or implementation necessitated another entry.