Hi Dieter,
I've always been told to steer clear of the IDENTITY in the past because it has some limitations in the past. Such as the gaps in numbers and the limit to the number of values that could be incremented. Meaning, it would run out of numbers and begin to wrap around and start over, using numbers that may have already been used in the past. Do you know if these limitations have been corrected by 13.10? We are considering using this IDENTITY feautre as we just need a unique value for a surragote key and do not care if there are gaps in the sequence. I also thought there were some ETL limitations possibly when using FASTLOAD or MLOAD to populate a table that has an IDENTITY column.
Thanks, Mike
Hi Dieter,
I've always been told to steer clear of the IDENTITY in the past because it has some limitations in the past. Such as the gaps in numbers and the limit to the number of values that could be incremented. Meaning, it would run out of numbers and begin to wrap around and start over, using numbers that may have already been used in the past. Do you know if these limitations have been corrected by 13.10? We are considering using this IDENTITY feautre as we just need a unique value for a surragote key and do not care if there are gaps in the sequence. I also thought there were some ETL limitations possibly when using FASTLOAD or MLOAD to populate a table that has an IDENTITY column.
Thanks,
Mike