Earlier in this thread it has been established that you can not put a bigger number into a smaller one if the bigger number is more than the system with smaller values can handle. I think the problem was to convert the 10 digit into an 8 digit number. Since he usese alpha-numeric values for the 8 digit number he can represent a bigger value in the 8 digits than he can in the 10 digit numeric value.
As long as nelsonyam1935 is aware that the biggest number he can use is the biggest value from the one system, witch is capable to hold the smaller biggest value, he should be fine. (That was a confusing sentence ).
He mentioned that the newer Database is using the 10 digit numeric value. Therfore he should be pretty safe, as you can assume you rather get new values from the new database and convert it into the old one. Hence, you convert the 10 digits decimal into a 8 digit with base 36. (smaller into bigger). However, you are right, without a check not to use an invalid number, he might run into a problem down the road.
Also, I mentioned I was not sure I got the problem right It was just a suggestion...
I'm going by the thread title here: conversion of 10-digital id to 8-digital id
Only one directional conversion not backwards
I felt like I need to be more specific.
If you assume the new database delivers the new values you never get one bigger than 9999999999. So the backwards conversion from the old db into the new one will only be for sync reasons. You could assume that this number already fits into a decimal system. Even so the 8 digital alpha-numeric value theoretically could hold a bigger number.
One directional conversion for the new values and two directional conversion for sysc-ing the two db's.