Здравствуйте не могу понять в чем проблема. в FIREBIRD в таблице PRODUCTS в поле PROD_CODE имеется запись 1234567890 запись в файл test.csv происходит успешно данные записываются в том же виде 1234567890, но если добавить еще один символ в поле PROD_CODE допустим 12345678901 то уже в файл записывается -53922298700 PROD_CODE тип данных NUMERIC (13,0) если в поле больше 10 символов, то выводиться непонятные значения. $sth = ibase_query($dbh,"SELECT PROD_CODE FROM PRODUCTS" ) or die(ibase_errmsg()); $myrows6 = ibase_fetch_assoc($sth); $ft = fopen('test.csv','w+'); do { $str1 = $myrows6["PROD_CODE"].";"; fwrite( $ft,$str1); } while ($myrows6 = ibase_fetch_assoc($sth)); fclose($ft);
var_dump(PHP_INT_MAX); и ты увидишь какие целые числа разрешены в твоей системе. сделай PROD_CODE строкой, проблемы отпадут. И запомни на будущее, все что по логике приложения не может складываться/делиться/умножаться в БД можно хранить строкой, даже если оно состоит из одних цифр.
В том то и дело что с таблицей никаких оперций производить нельзя т.к нарушится работа другой программы. С таблицы мож только вытаскивать данные. В даном поле происходят математические действия (( var_dump($myrows6["PROD_CODE"]); выводит string(10) "-539222987" Как же быть? В FIREBIRD есть наподобе mysql команда LOAD DATA OUTFILE для быстрой записи данных в файл?
омг Значит это произошло при записи, а в БД так и лежит Скачай IBExpert. и в нем ручками посмотри что у тебя в БД. Если именно эти цифры, то разбирайся с тем как ты записываешь и что вычисляешь. Это PROD_CODE Ты прикалываешься? Или номера телефонов ты тоже складываешь/вычитаешь? http://books.sysfaq.ru/DB/Interbase/Interbase_intro.pdf http://www.ibase.ru/v6/doc/langref.zip
Смотрел в БД лежит именно 12345678901 а php выдает -539222987 До 10 чисел все нормально а вот 11 и больше символов, беда. Данную таблицу использует программа автоматизации магазина в поле PROD_CODE записываются уникальный код товара состоящий из 12 символов. В таблице нельзя изменять тип данных потому что если чет поедет может и не сразу из за этого то будет П....
John-S, с магазином там все понятно. Хотя если грамотно подойти да отладить на тестовом стенде, то ничего не поедет. А так - делай отладку. Оно что при ibase_fetch_assoc() тебе сразу отрицательное выдает?
да сразу при $myrows6 = ibase_fetch_assoc($sth) выдает такой результат. Пробывал загонять результат в переменные разных типов но реакции никакой. Что еще мож придумать? За книжки огромное спасибо!!! С прогой по автоматизации магазина и с FIREBIRD столкнулся в первые. Так что лезь в структуру таблицы чет пока не хочется. Нужно всего лишь вытащить данные, так то все хорошо а вот с этим полем проблема.
Могу предложить финт ушами. Пишете хранимую процедуру которая выполняет нужный вам запрос, но попутно приводит тип этого поля к строке и вместо запроса обращаетесь к этой процедуре. Или просто делаете [sql]SELECT чего-то там, 'a' + CAST(PROD_CODE as varchar) FROM откуда-то[/sql] А в PHP уже обрезаете первую букву 'a' у этого поля (правильный синтаксис конкатенации строк в FB посмотрите в справочниках там не + используется) Ну или поколупать настройки и флаги php_ibase, но это скорее всего не поможет.
Результат бывает не только отрицательный при записи других данных в поле больше 10 знаков бывает и положительные, всякий разный, но только не тот который надо. Происходит как я понимаю переполнение мак. значения типа
$sth = ibase_query($dbh,"SELECT PROD_CODE, PROD_NAME, PROD_REST , 'a' || CAST(PROD_CODE as VARCHAR(80)) FROM PRODUCTS" ) or die(ibase_errmsg()); Не хочет прибавлять a к PROD_CODE результат вывода не меняется ((
дык? это что? Ты же в другом месте его прибавляешь, туда и смотреть надо. попробуй так [sql]SELECT ('a' || CAST(PROD_CODE as VARCHAR(80))) as PROD_CODE, PROD_NAME, PROD_REST FROM PRODUCTS[/sql] или так [sql] SELECT CAST('a' || CAST(PROD_CODE as VARCHAR(80)) as VARCHAR(81)) as CUSTOMFIELD FROM PRODUCTS[/sql]
О даааа!!! Моим мучениям пришел конец. Первая строчка работает!! Спасибо тебе огромное ВЕЛИКИЙ Simpliest