|
|
|
Из MSSQL поле binary в integer VFP9
|
|||
|---|---|---|---|
|
#18+
Ухожу в творческий отпуск часа на 2, чтобы обдумать подсказанное. Как жаль, что сегодня пятница, и через 2 часа трудно ожидать поддержки! Спасибо откликнувшимся! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:35 |
|
||
|
Из MSSQL поле binary в integer VFP9
|
|||
|---|---|---|---|
|
#18+
Поддержка будет и после 2 часов, только внимательнее читайте и хорошенько обдумывайте написанное Вам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:40 |
|
||
|
Из MSSQL поле binary в integer VFP9
|
|||
|---|---|---|---|
|
#18+
С другой стороны в МССКЛ Квери select convert(integer,0x202031384f202020) дает 1327505440 , а select convert(integer,0x2020204b71202020) дает 1897930784 - несомненные цифровые строки или же числа. Что это, почему отличается от полученного в Фоксе-не знаю пока, как и проблему взаимно однозначного соответствия таких конвертаций. И что за настройки сервера? Остался кто, а-у-у-у! - Угу-угу-угу! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 16:51 |
|
||
|
Из MSSQL поле binary в integer VFP9
|
|||
|---|---|---|---|
|
#18+
Для совсем плохо читающих повторяю в третий раз: Специально для плохо умеющих читать повторяю: Там хранятся строки. А тип binary сделан для исключения конвертаций содержиого такого поля при неправильных настройках сервера и/или клиента. А для генерации используется 36-ричная система. Понятно почему я написал select convert( char(8) , id), convert(char(8), parentid) from #t а не так подавляюще действующий на некоторых инт? Еще раз обращаю вниманию особо плохо читающих, что у меня стоит char(8)? а отнюдь не integer. Это очень плохо видно? Короче, еще один раз увижу integer - и на мою дальнейшую поддержку можете не расчитывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2007, 17:06 |
|
||
|
Из MSSQL поле binary в integer VFP9
|
|||
|---|---|---|---|
|
#18+
AMorkovka... Dima T, спасибо, поразмыслю над кодом. Пока никаких окончательных выводов не сделал, слишком быстро. Код не совсем понятный т.к. заточен под скорость, а не читабельность. Плюс переделка на скорую руку из 62=>10. Читабельней так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1C7 использует 36-ричную кодировку: 36100011......99A10B11......O24......Z35 В DBF-е у них тип поля С(8) причем пишется как-то в середину, например " 6S " 1С перенесла DBF на SQL один в один. Почему ключ стал BINARY(8) а не CHAR(8) только им известно. В твоем примере: 0x202031384f202020 0x20 => код пробела 0x31 => код символа "1" 0x38 => код символа "8" 0x4f => код символа "O" по хорошему надо делать alltrim() => "18O" а дальше пересчитывать: 1 * 36^2 + 8 * 36 + 24 = 1608 или (как в функции, чтобы в степень не возводить) (1 * 36 + 8) * 36 + 24 = 1608 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2007, 09:24 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=34802428&tid=1588769]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 196ms |
| total: | 358ms |

| 0 / 0 |
