я сталкиваюсь, очень часто :(
Самое простое, выгрузить неработающий объект из pbl во внешний файл, убить объект в pbl, попытаться скомпилировать этот pbl в pbd. Потом импортировать объект обратно в pbl. И сделать ему принудительный Regenerate. Может помочь.
Совсем радикальный способ - выгрузка всех объектов из pbl во внешние файлы, стираем pbl файл и делаем совсем новый pbl, потом загружаем все объекты обратно в новенький pbl. На месяц-два от этого глюка избавишься :)

Филипп
У нас тут этот метод называется "Wave the dead chickens" то-бишь "Размахивание дохлыми курицами".
Я знаю что это за метод :) Впрочем слышал это определение раза два всего.

Филипп
select error: data-conversion resulted in overflow - типичная ошибка для несовпадения размера колонки в DW с её размером в СУБД...
Все верно, но проблема в том, что если поменял ширину колонки в базе, потом поменял ширину колонки в dw - далеко не факт что ошибка исчезнет. Ну не всегда PB соображает что надо сделать полную рекомпиляцию объекта. Ну увы!

Филипп White OwlНу не всегда PB соображает что надо сделать полную рекомпиляцию объекта. Ну увы!
А это что за бред?
Dataobjects НЕ компилируются.
Ну да, конечно не компилируются! Ты в pbl загляни. Чем там половина места занята? Байт-кодом она занята. PB хранит в pbl как текстовое описание всех объектов, так и скомпилированное. При "компиляции" в pbd процесс компиляции всех текстовых описаний повторяется.

ФилиппДругого метода их "это" сделать кроме как поменять в painterе или в Edit Source - НЕТ.
Если под "их это" понимается изменить ширину колонки в dw, то все верно, это делается в дизайнере или в текстовом описании dw. А вот потом PB должен заново скомпилировать поправленый объект в байткод и сохранить этот байткод в pbl. Так вот если сохранять поправленый объект с тем же именем - PB не всегда делает перекомпиляцию. Если с новым - скомпилирует. Ну глюк это!
На который автор первого поста и наткнулся:
savosin_sergey делаю для этого неработающего DW save as.. с другим имемен -- всё работает

ФилиппБред.
В пиббле те части ДВ, в которых а) написаны РАЗМЕРЫ колонок и б) написан SQL запрос - голый текст, какая на хрен перекомпиляция...
То есть по мнению такого аса в PB как Филипп, PowerBuilder это чистый интерпретатор :)
Эх, блин, бросить все, уехать в Бостон....

ASCRUSФилипп абсолютно прав - DW это просто голое текстовое описание, которое просто не может компилироваться.
И ты Брут?!
А ну-ка, хекс-редактор в руки и шагом-марш смотреть внутренности pbl!

ASCRUS Фактически его можно рассматривать просто как текстовый ресурс, который хранится в PBL, с таким же успехом мы могли бы хранить его в файле или БД и поднимать во время работы программы.
Вот здесь все абсолютно верно :)

Anatoly MoskovskyВы все неправы. :-))
Не все... я все же прав :)

Anatoly Moskovsky3) Edit Source (он же Import) вполне достаточно для изменения ширины столбца (никакой частичной перекомпиляции нет).
Частичной нет, есть полная перкомпиляция исправленного объекта в бинарный вид.

E-docВсегда было интересно, откуда людям удается брать такую информацию о внутреннем устройстве PB. Может я не ту документацию читаю? Или это установлено научными методами (вроде "метода научного тыка")? :)
Сначала общая теория трансляторов подсказывает нам что PB относится к классу incremental compiler. Потом уже зная где искать, смотрим внутри pbl и видим подтверждение - смесь бинарных и текстовых данных.

ФилиппБред.
Какое именно месте тебе кажется неверным? Скажи конкретно, я тебе подскажу как проверить.

ФилиппНЕ компилируются в ПИББЛЫ dataobjectы, они в них ПИШУТСЯ.
Сделай full regen приложения, в котором есть пибблы, где только dataobjectы, и посмотри, изменилось в них что-нибудь или нет.
Промигрируй приложения, в котором есть пибблы, где только dataobjectы, и посмотри, изменилось в них что-нибудь или нет.
И это называется эксперимент? Я до последнего момента надеялся что у тебя есть какое-то сокровенное знание... К сожалению ты просто не знаешь того как работает компьютер :(


Делаем раз: Создаем пустую pbl.
Делаем два: Создаем в ней простейшее DW. Ну например tabular-external типа.
Делаем три: Сохраняем DW как dw_test
Делаем четыре: Закрываем PowerBuilder и открываем любую утилиту которая может смотреть внутренности нетипизированного файла. Я использовал FAR, но если желаешь, можешь взять hiew или bview.
Итак, что мы видим внутри нашей test.pbl?

Сначала идет заголовок PBL (HDR*PowerBuilder).
С адреса 0x400 идет описание файлов внутри pbl.
С адреса 0x420 начинается описание первого файла, оно переменной длины. Со смешения +8 четыре байта указывают на адрес данных внутри pbl, со смещения +24 лежит ASCIIz имя файла.
В нашей test.pbl, в которой мы создали только один DataWindow object мы видим два(!) файла. Первый имеет имя dw_test.srd, второй dw_test.dwo.
Давай теперь посмотрим повнимательнее на эти два файла. Смотрим по адресу +8 четыре байта, выписываем их на бумажку и отматываем test.pbl на этот адрес.
Первый выглядит очень знакомо, да это текстовое описание нашего DW. То самое что ты увидишь при "Edit Source".
А вот второй файл (который носит имя dw_test.dwo) выглядит сплошным мусором. Однако, если присмотреться, ты в нем найдешь много интересных текстиков, свой SELECT, имена колонок и даже данные (если DW было объявлено External-типа).

А вот теперь, господин любитель смотреть размеры файла, скажи мне что такое dw_test.dwo и зачем PowerBuilder положил его внутрь pbl?

Для полноты картины:
Длина файла указана в директории по смещению +12.
Файлы хранятся по страничному принципу. Размер страницы 0x200, каждая страница начинается с метки "DAT*" а со смещения +4 четыре байта указывают адрес страницы со следующим куском файла.

Если мы сделаем на основе нашей pbl pbd, мы увидим точно такую же внутреннюю структуру библиотеки. Только в pbd будет лежать всего один файл dw_test.dwo и если его выкусить из pbd и сравнить с аналогичным файлом из pbl - отличий не обнаружишь совсем.

Так все таки, когда была произведена первая компиляция DataWindow? При сохранении в редакторе или только при Build Runtime Library?

А если бы ты поизучал такую науку как computer science и конкретно раздел "теория трансляторов" ты смог бы это все предсказать и сам. Видел бы как работает среда, знал бы чего от нее ожидать и где что искать при необходимости уточнений.

ФилиппГде ответ на мой вопрос:
Сделай full regen приложения, в котором есть пибблы, где только dataobjectы, и посмотри, изменилось в них что-нибудь или нет.
Не должно измениться. Потому что каждый раз, при сохранении любого (в том числе dataobject) объекта в библиотеке, PowerBuilder делает перекомопиляцию сохраняемого объекта. Если после full regen приложения pbl изменилась - значит в этой pbl был, по какой-то причине, не правильно скомпилированный объект.

ФилиппПромигрируй приложения, в котором есть пибблы, где только dataobjectы, и посмотри, изменилось в них что-нибудь или нет?
Если миграция делается из одной версии PB в другую, то да, новый pbl не будет равен старому. Потому что все объекты будут заново перекомпилированы из старого диалекта в новый. Изменения будут хотя бы в заголовке скомпилированных объектов. У dwo от PB9 в заголовке легко можно увидеть сигнатуру "PDW0900". Но чтобы увидеть эти изменения вам все же прийдется сделать побайтное сравнение двух pbl.

ФилиппС самого начала я сказал, что делать full regen/rebuild в надежде, что это подправит dataobjects - это Waving the dead chickens , и повторю это ещё раз.
Это не подправит dataobjects это подправит библиотеку (pbl) в той части которая хранит скомпилированый вариант dataobject.

ФилиппЕдинственная надежда подправить dataobjects глобально - это Optimize the pibble, как прально укал г-н Московский, о чём и SaveAs успехи намекали.
Ну и как по вашему происходит "Optimize the pibble"? Ну? Хоть один вариант отличный от описаного мной?

Может еще объясните что это за слово такое "pibble"? Ни в одном словаре не нашел :) PBL - Power Builder Library, произносится "пибл", но пишется PBL.


ФилиппЗа 9 лет РВ я ни разу не видел подобных проблем с dataobjects, с КОДОВЫМИ объектами - да и неоднократно (вот там как раз и перекомпиляция).
Вы очень везучий человек Филипп. Очень-очень. А может пишете свои проекты в одиночку и не передаете объекты и целые pbl между группой разработчиков. А может просто привираете? :)

ФилиппВсё, умолкаю, мы поняли уже, что вы крутой computer Scientist...
Благодарю за комплимент. Я люблю то чем занимаюсь и занимаюсь тем что люблю :)

ГеннадичСдаётся мне, что White Owl перепутал понятия dataobjects и окно датавиндов, в смысле d_datawindow и dw_datawindow. Первое действительно лежит открытым текстом в ".PBD".
Еще один... Ну объясни мне тогда в чем разница между d_datawindow и dw_datawindow. Заодно пойди внимательно прочитай все что я писал на эту тему и укажи где конкретно я ошибаюсь и докажи мою ошибку. Все очень просто :)
А если ты еще сходишь в PBD и найдешь мне там "открытый текст" я буду просто на седьмом небе от счастья!

alexis glinskiрекомендую всем поверить Anatoly Moskovsky , и для экспериментов воспользоваться его pblDump + FAR. Вот здесь :)
Московский кстати тоже ошибается в некоторых утверждениях. А конкретно: DW Painter не читает бинарный вариант dw. Painter тоже читает текстовый формат и на лету делает расшифровку. Если бы он читал именно бинарный вариант, то в случае повреждения pbl и расхождения двух копий dw (srd не равно соотвествующему dwo), при открытии dw через графический или текстовый редакторы мы бы увидели разницу в dw и сохрание dw с новым именем не лечило бы проблему. Однако такие расхождения вылазят всегда только в рантайме. Вывод - первичным все же является текствое определение dw.

Anatoly MoskovskyПоменяй в бинарнике какую-нибудь строковую константу и открой потом DW в паинтере, потом в тут расскажи, что вышло.
Хм.... Действительно. Получил два разных dw для Painter и Edit Source. На Save в Painter обновился srd... Признаю, в этом вопросе ты был правее.

Вообще-то это идиотизм читать бинарный вариант при паралельном существовании парсера из текстового формата. Это ж им приходится заниматься паралельной поддержкой двух взаимозаменяемых функций... Чем дальше тем меньше мне нравится архитектура PB :(