я сталкиваюсь, очень часто :(
Самое простое, выгрузить неработающий объект из 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 :(

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

Кстати, промигрированные dataobjects имееют право не иметь новых пропертей добавленных в новой версии. Многие-многие системы не добавляют в описание объекта параметры, значения которых не отличаются от значений по умолчанию. И мигрировавший в такой системе объект не будет ничем отличаться от старого. Я не знаю относится PowerBuilder к таким системам или нет. Последний раз я делал миграцию пару лет назад, а в те времена меня такие вопросы не интересовали :)


Филипп
The Computer Scientist
Ну и как по вашему происходит "Optimize the pibble"? Ну? Хоть один вариант отличный от описаного мной?
Вы мне тут пишите что regen сделает то же самое, что Optimize, а я вам ещё раз повторю, что в отношении dataobjects - НЕТ.
Аааа... так вы про пункт контекстного меню "Optimize"! Я то думал вы о процессе оптимизации, а вы всего-лишь про кнопку... Ну хорошо, кнопка Optimize делает дефрагментацию страниц внутри pbl. И не делает перекомпиляции текстовых описаний в байткод. И даже не декомпилирует байткод в текст.
Зато она перетаскивает все откомпилированные файлы в начало pbl а текстовые в конец.
Довольны?

Филипп, мой ник - White Owl. Называйте меня пожалуйста именно так.

Филипп White Owl
Филипп, я не понял. Я разве сказал что-то неправильно? С чем вы не согласились на этот раз?
С тем, что сигнатуа "PDW0900" в пиббле РВ9 имеет отношение к обсуждаемому вопросу (подпраленному/неподправленному dataobjectу).
Единственное к чему она имеет отношение - к ФАКТУ, что это пиббл версии РВ9

Вообще-то, упоминая эту сигнатуру я отвечал на вот этот вопрос:
ФилиппПромигрируй приложения, в котором есть пибблы, где только dataobjectы, и посмотри, изменилось в них что-нибудь или нет?
Я показал что там измениться даже в самом минимальном варианте. И изменения эти будут находится именно в скомпилированном описании dataobject'ов.

И во вторых, данная сигнатура ничего не говорит о версии PBL. Она говорит о версии PB в котором был скомпилирован данный dataobject :)

Филиппdataobjects НЕ компилируются. Эта сигнатура говорит о том, что этот pibble - 9-й версии Powerbuilderа.
Ни как не пойму, вы прикалываетесь или что?
Ну хоть какое-нибудь обоснование ваших утверждений о "некомпилируемости" можно услышать?
И еще раз повторю: версия dwo и версия pbl это две разные вещи. PB9 использует тот же самый формат pbl что и PB6. И это легко может увидеть любой кто посмотрит внутрь pbl, по адресу 0x12.

ФилиппАга, то-то РВ9 как-то знает, что ты пытаешься РВ6ную пиблу в либ лист поставить...
Мдя? У меня сейчас нету PB6, но pbl от PB7 добавился в PB9 проект без единого вопроса. Что я делаю не так?
ФилиппНо ваще - НЕ прикалываюсь. В Pibble кодовые объекты компилируются, а daatobjects НЕТ :-)
Ну почему нет? Ну хоть один аргумент приведите!
Ответьте на вопрос: Что такое dwo файлы, которые хранятся в pbl и pbd?
Я на ваши вопросы отвечаю, ответьте и вы на мои.