sobitie = 'Заселен в "' || :v_hostel_naim || '" комната № "'
|| :v_room_naim || '". ' {здесь нужен возврат каретки};
sobitie = sobitie || 'Ордер ' || :v_hostel_nom || '/'
|| new.zaselenie_id || ' действителен с '
|| new.data_nach || ' по ' || new.data_kon;
execute procedure ins_history(new.client_id, sobitie);
Возврат каретки
СУБД Firebird 2.1 (если необходимо, то 2.5)
Перерыскал форум и спрашивал у гугла, но не нашел.
Господа кодеры, подскажите, пожалуйста, как применить возврат каретки. Точнее каков код.
Пример:
/r/n не подходят, CHR(13) || CHR(10) тоже не идет.
Перерыскал форум и спрашивал у гугла, но не нашел.
Господа кодеры, подскажите, пожалуйста, как применить возврат каретки. Точнее каков код.
Пример:
Код:
/r/n не подходят, CHR(13) || CHR(10) тоже не идет.
Попробуйте так:
Код:
declare crlf varchar(2);
crlf = '
';
str = str1 || crlf || str2;
crlf = '
';
str = str1 || crlf || str2;
разделяйте работу с данными и пользовательский вывод.
В строке символ "перевод каретки" бессмысленен - задумайтесь над этим. У строки есть начало и конец. Поэтому гугл вам и не смог ответить.
Чего вы пытаетесь добится?
В строке символ "перевод каретки" бессмысленен - задумайтесь над этим. У строки есть начало и конец. Поэтому гугл вам и не смог ответить.
Чего вы пытаетесь добится?
Цитата: kot_
разделяйте работу с данными и пользовательский вывод.
В строке символ "перевод каретки" бессмысленен - задумайтесь над этим.
В строке символ "перевод каретки" бессмысленен - задумайтесь над этим.
Ну здесь я бы не согласился. Символ перевода строки такой же символ как и другие и имеет право быть использованным в строке) Тем более, если заранее известно, как должна быть отформатирована строка. Кроме отображения строки пользователю может быть задача, например, помещения какой-то текстовой информации в лог.
ну во первых - "разделяйте работу с данными и пользовательский вывод" - это тоже не согласен?
Во вторых - повторюсь - для начала в строке символ перевода каретки - бессмыслен, второе - в различных системах он разный. В третьих - перевод каретки - это пользовательский вывод - причем тут логи? отчеты тоже в лог будем помещать в вордовском формате? чушь.
Во вторых - повторюсь - для начала в строке символ перевода каретки - бессмыслен, второе - в различных системах он разный. В третьих - перевод каретки - это пользовательский вывод - причем тут логи? отчеты тоже в лог будем помещать в вордовском формате? чушь.
Цитата: hardcase
Сколько помню, эскейпы через \ писались:
Код:
\r\n
а потом следующий вопрос от аффтора - "почему строка не полностью передается". :)
ИМХО стоит пояснить что так делать не надо. Да и самому какгбы внимательней надо быть.
Не совсем понимаю, что имеется в виду под разделением работы с данными и пользовательским выводом? Если я формирую строку на сервере, почему я не могу ее отформатировать нужным мне способом для отображения на клиенте, например сообщение об ошибке.
Насчет логирования - я также могу поместить в лог-таблицу уже отформатированную строку и при необходимости просмотреть в удобочитаемом виде ее содержимое в любом инструменте, работающим с моей СУБД, чем для этого писать специальную прогу для форматирования и отображения лога.
По поводу "в различных системах он разный" - в моем примере сами коды будут генерится той средой, в которой разрабатывается код процедуры.
Насчет логирования - я также могу поместить в лог-таблицу уже отформатированную строку и при необходимости просмотреть в удобочитаемом виде ее содержимое в любом инструменте, работающим с моей СУБД, чем для этого писать специальную прогу для форматирования и отображения лога.
По поводу "в различных системах он разный" - в моем примере сами коды будут генерится той средой, в которой разрабатывается код процедуры.
Цитата: Ora-cool
Попробуйте так:
Код:
declare crlf varchar(2);
crlf = '
';
str = str1 || crlf || str2;
crlf = '
';
str = str1 || crlf || str2;
Ora-cool, спасибо огромное! Все гениальное просто! Все заполняется на УРА!
Цитата: hardcase
Сколько помню, эскейпы через \ писались:
Код:
\r\n
hardcase, просто перепутал. Бывает... =)
Цитата: kot_
разделяйте работу с данными и пользовательский вывод.
В строке символ "перевод каретки" бессмысленен - задумайтесь над этим. У строки есть начало и конец. Поэтому гугл вам и не смог ответить.
Чего вы пытаетесь добится?
В строке символ "перевод каретки" бессмысленен - задумайтесь над этим. У строки есть начало и конец. Поэтому гугл вам и не смог ответить.
Чего вы пытаетесь добится?
Нехорошо это, когда в клиенте данные как-то обрабатываются, ИМХО.
Цитата: Ora-cool
Ну здесь я бы не согласился. Символ перевода строки такой же символ как и другие и имеет право быть использованным в строке) Тем более, если заранее известно, как должна быть отформатирована строка. Кроме отображения строки пользователю может быть задача, например, помещения какой-то текстовой информации в лог.
+1
Дело в том, что на любое изменение какого-ли поля в к.-л. таблице, создается запись в таблице истории, в которой отображается ЧТО БЫЛО и ЧТО СТАЛО. Но если изменены сразу несколько полей, то либо создается несколько записей в истории, либо все это закидывать в одну запись. И поэтому необходим был возврат каретки для удобочитаемости. А текстовому полю не имеет значение какие символы хранить...
Всем спасибо огромное за помощь!
Цитата: Ora-cool
Не совсем понимаю, что имеется в виду под разделением работы с данными и пользовательским выводом? Если я формирую строку на сервере, <skiped>...</skiped> - в моем примере сами коды будут генерится той средой, в которой разрабатывается код процедуры.
угу. угу.
лично мне подобный подход просто кажется диким. Потому как я еще помню утро 4 января 2000 года и окуевше-пьяные глаза главбуха, у которого просто лягла база. Чессслово, не знаю руководствовались ли разработчики похожими аргументами, либо на то что бы хранить в базе 2 цифры вместо 4, или они обосновывали чем то другим - уже не помню.
Я лично считаю подобный подход не очень удачным - а точнее крайне не удачным, ввиду того, что клиент может получать данные куда угодно - и хранить в БД символ перевода строки, который не факт что будет совпадать с клиентским - ну по меньшей мере не очень разумно - в конце концов, если вам так хочется использовать форматирование - ну так используйте XML либо его аналог - формируйте шаблон - ИМХО.
Ну пример с 2000 годом не очень связан с текущей темой)
Я не утверждаю, что данное решение всегда оправданно, но есть случаи - как с тем же логированием, когда оно вполне имеет место быть.
Я не утверждаю, что данное решение всегда оправданно, но есть случаи - как с тем же логированием, когда оно вполне имеет место быть.
Цитата: Gluckodrom
Нехорошо это, когда в клиенте данные как-то обрабатываются, ИМХО.
да что ты такое говоришь? :)
задача БД - хранить данные. задача клиента - обрабатывать их и быть посредником между БД и пользователем, предоставляя интерфейс.
Цитата: Washington
задача БД - хранить данные. задача клиента - обрабатывать их и быть посредником между БД и пользователем, предоставляя интерфейс.
Это уже начинается идеологическая дискуссия) Я бы сказал, что обработка данных - это тоже ближе к БД (если классический клиент-сервер, а не 3-звенка). А клиент - это ввод-вывод.
Цитата: Ora-cool
Ну пример с 2000 годом не очень связан с текущей темой)
Я не утверждаю, что данное решение всегда оправданно, но есть случаи - как с тем же логированием, когда оно вполне имеет место быть.
Я не утверждаю, что данное решение всегда оправданно, но есть случаи - как с тем же логированием, когда оно вполне имеет место быть.
я свою позицию объяснил - в конце концов - это проблема топикстартера. Лично ИМХО вероятно есть случаи, когда подобное решение имеет место быть - но лично я о таких не знаю. И этот случай - скорее ошибка проектирования.
А с "ошибкой 2К" как раз таки и связано на прямую - когда разработчик БД решал (!!!), хватит ли двух знаков, либо надо четыре - вместо того, что бы просто оставить эту задачу клиенту. С моей точки зрения это не более глупо, чем беспокоится о переносах строк, ничего не зная о том, кто эти строки получит.
Но опять же - это проблема топикстартера.
Цитата: Ora-cool
Это уже начинается идеологическая дискуссия) Я бы сказал, что обработка данных - это тоже ближе к БД (если классический клиент-сервер, а не 3-звенка). А клиент - это ввод-вывод.
да, возможно. но в клиень-серверной архитектуре я все же предпочитаю на серверной стороне только хранить данные. а на клиентской обрабатывать + ввод-вывод. объяснения моему предпочтению достаточно простое - мне легче обработать данные с помощью языка Delphi/Python чем языком SQL. возможно это от плохого знания SQL, но по мне, так он просто неудобен.
Цитата: kot_
я свою позицию объяснил - в конце концов - это проблема топикстартера. .
Вот с этим полностью согласен)
Цитата: kot_
А с "ошибкой 2К" как раз таки и связано на прямую - когда разработчик БД решал (!!!), хватит ли двух знаков, либо надо четыре - вместо того, что бы просто оставить эту задачу клиенту. С моей точки зрения это не более глупо, чем беспокоится о переносах строк, ничего не зная о том, кто эти строки получит.
Но опять же - это проблема топикстартера.
Но опять же - это проблема топикстартера.
А вот с этим категорически не согласен. Как раз разработчик БД и должен решать, сколько выделить для хранения того или иного значения. Т.к. схема данных содержится именно в БД. А клиентское приложение должно просто позволять вводить/отображать это значение.
Цитата: Washington
да, возможно. но в клиень-серверной архитектуре я все же предпочитаю на серверной стороне только хранить данные. а на клиентской обрабатывать + ввод-вывод. объяснения моему предпочтению достаточно простое - мне легче обработать данные с помощью языка Delphi/Python чем языком SQL. возможно это от плохого знания SQL, но по мне, так он просто неудобен.
Да, я думаю это как раз от неумения готовить SQL (+расширение SQL конкретной СУБД), либо от использования СУБД с малыми возможностями. Преимущества от переноса логики на сервер описывать не буду - этого достаточно описано в литературе)
Цитата: Ora-cool
А вот с этим категорически не согласен. Как раз разработчик БД и должен решать, сколько выделить для хранения того или иного значения. Т.к. схема данных содержится именно в БД. А клиентское приложение должно просто позволять вводить/отображать это значение.
:)
т.е. отображать данные - это задача клиента - но мы за него ее решим? :)
ты путаешь "перенос логики на сервер" - с "отображением данных". В большей части - это будет крайне корявое и негибкое решение. Но ты утверждаешь что знаешь случаи когда это единственный выход. Я же говорю что практически в подобном решении нет необходимости - потому что хранить в БД мы можем все что угодно - но пусть клиент сам решает - что и как показывать. Ведь только ему известна конечная цель и характеристики отображения
может быть конечно не настолько уж "корявое и негибкое" - но лично я не вижу необходимости вот именно в таком подходе. Если нам нужно хранить документ, форматирование которого является частью данных (ну например - какой нибудь договор и т.п.) то да, возможно формировать его на сервере подставляя готовые данные - и возможно это каким то образом оправданно (да и то - от задачи зависит).
Смысл же хранить в базе перенос строк, да еще и таким образом, да еще и так аргументировать - от меня ускользает. Глубоко мое ИМХО.
Смысл же хранить в базе перенос строк, да еще и таким образом, да еще и так аргументировать - от меня ускользает. Глубоко мое ИМХО.
Цитата: kot_
т.е. отображать данные - это задача клиента - но мы за него ее решим? :)
ты путаешь "перенос логики на сервер" - с "отображением данных".
ты путаешь "перенос логики на сервер" - с "отображением данных".
Мое высказывание относилось к описанной тобой "проблеме-2000". Бяка ведь была не из-за корявого отображения, а из-за того, что разработчик БД не отвел нужного кол-ва разрядов для поля в БД.
Цитата: kot_
Смысл же хранить в базе перенос строк, да еще и таким образом, да еще и так аргументировать - от меня ускользает. Глубоко мое ИМХО
Я уже привел свои аргументы, когда, на мой взгляд это оправданно. Речь не шла о хранении данных бизнес-логики, а о хранении вспомогательной информации, такой как логи или передаче специальным образом отформатированной строки для отображения на клиенте.
Цитата: Ora-cool
Мое высказывание относилось к описанной тобой "проблеме-2000". Бяка ведь была не из-за корявого отображения, а из-за того, что разработчик БД не отвел нужного кол-ва разрядов для поля в БД.
аргументируя это тем, что клиенту хватит двух знаков. :) (да, да я знаю - не всегда это была единственная причина - но я имею ввиду именно такие ошибки) именно этим и занимается топикстартер - решая как будет это отображаться на клиенте. Это ошибка - можно конечно придумывать и фантазировать (лучше в логах отображается и т.д.) - но лучше делать не через ж... :)
Цитата: Ora-cool
Я уже привел свои аргументы, когда, на мой взгляд это оправданно. Речь не шла о хранении данных бизнес-логики, а о хранении вспомогательной информации, такой как логи или передаче специальным образом отформатированной строки для отображения на клиенте.
ИМХО и еще раз ИМХО - здесь смешивается хранение и отображение данных, что в целом абсолютно не оправданно усложняет систему, так как (например) клиенту надо ЗНАТЬ о том, что в строке, которую он получает присутствуют управляющие символы, которые могут изменить отображение данных. Приведите мне пример когда это абсолютно оправданно - а не вызвано кривизной рук? Рассказы что так удобней - для меня абсолютно не убедительны - потому как в чем удобство я понять не могу. Вы действительно считаете удобным узенькую серенькую полоску текста с левой стороны монитора? Например? Я думаю что нет. Тогда зачем? Пусть клиент тогда и расставляет переносы строк, так как считает нужным. Если это надо - он может запросить нужный шаблон (опираясь на версию там и прочее), и в него уже размещать нужные данные. И ответ так проще и быстрее мне тоже не кажется убедительным - символ не печатный и явно не всегда может быть виден - а БД редко делают для решения сиюминутных задач - через год, хорошо если вы будете помнить,что вы туда запихивали (а при подобном подходе - я уверен, там будет стоооооолько разного - мало не покажется). Хотите показать что здесь вы считаете нужным перенос - ну так используйте XML/HTML либо на ваш вкус, явно предназначенное для разметки текста и пусть клиент принимает решение - как его отображать.
Вы не считаете это очевидным? Зачем же оправдывать "индусский подход"? Понятно что чем больше быдлокодеров - тем выше зарплата - но все равно...