Коля SbWereWolf

именно, большинство диалогов начиналось со слов «спам сервера на размещаем», когда я объяснял что всё легально, то тогда общение кто то продолжал, но большинство — нет. Кто то давал советы как в спам лист не загреметь.
Для меня лично это важный индикатор — если техподдержка настроена на диалог, то с ней можно работать.

извините

милый троллинг :)

+1 уволился с любимой работы ( любил её пять лет ), только потому что опыт который там получал, ни где больше спросом не пользовался.

тема раскрыта, любое изменение это всегда изменение ссылки, смотрим где поменялись ссылки — там перерисовываем.

познавательно, спасибо.

спасибо, очень помогло.

он не считал это мало вероятным, он об этом прямым текстом пишет в Сильмарионе: Моргот в своих подземельях из эльфов сотворил орков, потому чт оему нужны были прислужники и он их сделал из того что было: )

а где заключительное слово?

у Гугл почты есть подобная фишка, если письма от одного отправителя стабильно удаляешь, то через какое то время письма от этого отправителя складываются в спам.
Менюшка с папками и кругами всегда показывает только по 5 позиций, хочешь больше — наведи мышку, если надо ещё больше то нажми пункт «Ещё».

Изменение элементов интерфейса не замечал, но во многих Микрософтовский приложениях в меню показываются самые используемые пункты и остальные выводят или с задержкой или по нажатию кнопки со стрелочкой.

Изложенное в статье имеет место быть. Это толковая практика: )

прикольно

почитай Гумилёва «Конец и вновь начало», будешь спокойно относиться ко всем этим колебаниям курса.

всему своё время, если тебе кто то обещал раньше срока, то с него и спроси где оно твоё счастье.

В StartConflict в снайперском режиме сенс остаётся прежним, обычно у меня стоит 1600 dpi, для снайпа переключаюсь на 400, SC это не CS и не Quake, разрабы не предусмотрели снижения сенса при зуме.

«Microsoft Mouse Optical 1.1» да прикольная мыша, у меня года два в Старкрафт отпахала и умерла, в продаже давно этих мышей не видел, лет 8.

Пол года живу с «GAMING MOUSE x7» и бесконечно ей рад. Чёткий клик, мягкое нажатие, очень дискретный и лёгкий сроллинг, dpi можно переключать на ходу — что ещё надо для счастья?
Отличная офисная мышь :)) в StareConflict-е тоже не подводит, люблю её.
На работу такую же собираюсь купить.

При желании на три доп. кнопки можно какие то вещи повешать, но это рюшечки, и без них живётся хорошо.
Три доп копки, умножить ан 5 режимов, получаем 15 дополнительных функций, всё что хочешь можно забиндить, и не к чему из мышки делать вторую цифровую клавиатуру.

Решение любой задачи подразумевает выделение ресурсов — рабочего времени, были выделены сутки, в сутки я уложился.
В стратегическом плане конечно код будет в SVN / Mercurial храниться, опять же не раньше чем мне кто то выделит недельку на изучение этой темы применительно к СУБД ( PL/SQL Developer типа умеет работать с SVN, dbForge вообще с чем угодно, но что и как пока у нас ни кто не разбирался ).
Конечно у нас есть тестовый сервер, у нас даже есть сервер разработки, схема работы конечно такая: DEV — TEST — PROD.
Про "good practices" ни чего не слышал, мы в своей работе руководствуемся "best practices" :)
Oracle-based EPR из коробки с 20-летней историей — это Парус.
"Экземпляров" Паруса у нас кстати два, один клиент это завод с дискретным производством, другой клиент — продаёт услуги, у каждого своя специфика и за 10+ лет чуть более чем полностью переписанный функционал, так что от Паруса — там только название осталось.

Без понятия :)) считай эту сентенцию "старые версии объектов" авторской выдумкой, ради красного словца.
Может быть это не Oracle что то кэширует в сессии, а клиент ERP системы, и пока ERP клиент работает с устаревшими данными у пользователя происходят ошибки.

В представлении DBA_SOURCE есть типы объектов но у DBMS_METADATA.GET_DDL свои правила написания имён типов, и надо будет делать подмену 'PACKAGE' на 'PACKAGE_SPEC'
"alter session set current_schema=" — прикольно, это наверное и есть тот нюанс о котором знает "TOAD", но которого не знаю я.
"При этом, возможно, исходник возьмется из source ?" — без понятия, для себя я эту задачу решил и дополнительно тратить на неё время пока не хочется.

Из моего опыта, когда у тебя сваливается вся база, тысяч 15 процедур/пакетов/функций и ты пытаешься всё инвалидное откомпилить, да иногда приходиться убивать пользовательские сессии, а иногда без этого обходиться, да иногда пользователям надо перелогинится, а иногда без этого обходиться.
Мой опыт это год работы на Oracle 10g, за это время мы базу раз 10 роняли, раз на раз не приходиться, почему так — я не вникал.

Компиляция только на третьем шаге происходит, непосредственной подмены исходников — изменения записей таблицы SYS.SOURCE$ в алгоритме нет.
Собственно компиляция выполняется через "API" сервера, что бы сервер сам как ему надо все вопросы разрулил, и вообще был в курсе что у него исходники поменялись.
Пока не произошло компиляции ( CREATE OR REPLACE ) объекты себя ведут как всегда :)
После компиляции в некоторых сессиях могут вызываться старые версии объектов, поэтому если у пользователя что то "глючит", то ему просто надо перелогинится.

Не REGEXP_REPLACE — потому что я регулярными выражениями пользоваться не умею.
Не dbms_utility.COMPILE_SCHEMA — потому что это имело бы смысл при прямом изменении исходников в таблице SYS.SOURCE$, но мне не по себе от такого вмешательства в лоб.
Но конечно после того как все исходники будут обработаны — будет какое то количество INVALID объектов, поэтому как завершающий этап dbms_utility.COMPILE_SCHEMA — будет верным шагом, можно добавить в конец процедуры P_EXECUTE_CODE_UPDATE.

.

я ни чего не упускаю, вы пишите :

Отсутствие статистики

и т.п.
я пишу в статье:

Временная таблица может быть записана на диск и проиндексирована, временная таблица существует даже после завершения выполнения блока кода.
Табличная переменная существует только в оперативной памяти и только внутри блока кода и не может быть проиндексирована.

MSDN пишет:

Table variables does not have distribution statistics, theywill not trigger recompiles. Therefore, in many cases, the optimizer will build a query plan on the assumption that the table variable has no rows. For this reason, you should be cautious about using a table variable if you expect a larger number of rows (greater than 100).

что я упустил? у меня что количество колонок, что количество разделов в пределах десятка, мне надо тупо перебрать записи как элементы массива, зачем мне индексы? в чём я не прав?
В том что вы игнорируете описанные нюансы и настаиваете на единственно верном решении?

в нашем с вами обсуждении табличных переменных мы выяснили, что они бывают двух разных видов:

1. Disk-based
2. Memory-optimized

Теперь почитаем, что

Martin Smith

в своём коменте пишет:

Caveat

This answer discusses «classic» table variables introduced in SQL Server 2000. SQL Server 2014 in memory OLTP introduces Memory-Optimized Table Types. Table variable instances of those are different in many respects to the ones discuss

мой перевод «оптимизированные для памяти сильно отличаются от тех которые обсуждаются ниже, подробности по ссылке»,
перейдём по ссылку, и увидим:

The use of memory-optimized table variables has a number of advantages over traditional table variables:

• The variables are truly in memory: they are guaranteed to never spill to disk

Мой перевод: «Эти переменных истинно в памяти, они гарантировано ни когда не скидываются на диск»

поэтому касательно моей комента к коду, за который вы меня мурыжите:
```sql
/* очищаем табличную переменную — освобождаем оперативную память */
```
можно сказать следующее:

• если табличная переменная объявлена с типом имеющим «MEMORY_OPTIMIZED = ON» ( Memory-optimized ), то всё верно
• если это old school table variable — Disk-based, то комментарий вводит в заблуждение

а теперь вернёмся к:

Не знаю, почему Вы в негативном ключе воспринимаете мои слова

Который касается вашей адекватности, я о себе пишу:

мой первый опыт «серьезной» работы с T-SQL

Но вы из контекста статьи вырываете отдельные части и относитесь к моим словам как к изречению гуру по T-SQL.
А потом понеслось «в Интернете кто то не прав» :))
Надо оно вам?

про tempdb ок, пусть пишется. не в этом суть, суть моих возражений была в том что табличная переменная всегда использует оперативную память. вы с этим не согласились :

Также немного смутили комментарии

можно поиграться с кодом :

-- Test registration in tempdb
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables -- До объявления табличной переменной
GO
DECLARE @t1 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables -- После объявления табличной переменной
GO
SELECT COUNT(1) AS PAST FROM tempdb.sys.tables -- После блока кода с объявлением табличной переменной
-- Test Drop
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables 
GO
DECLARE @t2 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables 
DROP TABLE @t2
GO
-- Test Trunc
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables
GO
DECLARE @t3 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables
TRUNCATE TABLE @t3
GO
-- Test Delete
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables
GO
DECLARE @t4 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables
DELETE @t4
GO

но этом нам даст только, то что "DELETE " это единственный способ удалить записи из табличной переменной.

из моего списка "литературы" идём по ссылке Temporary Tables

находим текст :

If you are using SQL Server 2000 or higher, you can take advantage of the new TABLE variable type. These are similar to temporary tables except with more flexibility and they always stay in memory.

теперь курим MSDN

Like memory-optimized tables, memory-optimized table variables,

• Must fit in memory and do not use disk resources.

Disk-based table variables exist in tempdb. Memory-optimized table variables exist in the user database (but they do not consume storage and are not recovered).
You cannot create a memory-optimized table variable using in-line syntax. Unlike disk-based table variables, you must create a type first.

оказывается табличные переменные бывают двух типов:

1. Disk-based
2. Memory-optimized

Memory-optimized должны быть объявлены с использованием пользовательского типа, пример:

CREATE TYPE [Sales].[SalesOrderDetailType_inmem] AS TABLE(
  [ProductID] [int] NOT NULL,
  [SpecialOfferID] [int] NOT NULL,

  INDEX [IX_ProductID] HASH ([ProductID]) WITH ( BUCKET_COUNT = 8),
  INDEX [IX_SpecialOfferID] NONCLUSTERED 
)
WITH ( MEMORY_OPTIMIZED = ON )

1. должен быть минимум один индекс
2. обязательно "MEMORY_OPTIMIZED = ON"

ок.

справедливость восстановлена?

у меня тоже 5.1.1.178. Я не знаю что мне в саппорт написать, закономерность установить не получается, писать "оно у меня падает" мне совесть не позволяет. я сам по техподдержке постоянно такие письма получаю :)
Не суть. Когда мне надо будет по работе писать много T-SQL кода, тогда и разберёмся.

по поводу бесплатности это как бы не аргумент, суровая российская реальность с вами не согласиться. Одна половина фишек из джентельменского набора, другой половиной я не пользуюсь. По поводу стабильности читайте мой комент
Не знаю какой хороший инструментарий для MS SQL, а для Oracle я пользуюсь PL/SQL Developer и TOAD, мне хватает, dbForge — только как форматировщик.
ЗЫ
ссылку на dbForge я даю в своём списке ссылок, вы до этого места видимо не дочитали?

Не знаю уместно ли, но много лишнего кода

у меня в коде есть комментарий который поясняет этот момент — с правильным использование курсоров в T-SQL не было времени разбираться, это согласитесь не на пол часа занятие.
Получить набор данных и спокойно с ним работать, не парясь ни за какие нюансы — на мой вкус это хорошая практика.
Кто то пишет супер оптимизированный код, кто то пишет много элементарного атомарного кода — мне ближе второй подход, с точки сопровождения это более удобный вариант.

я привожу ссылку Временные таблицы на статью про временные таблицы и табличные переменные, там написано, что табличная переменная живёт только в оперативке, на stack overflow пишут, что дропнуть табличную переменную нельзя, потому что её на жёстком диске нет, это как бы намекает что табличные переменные в tempdb не пишутся.
Кто из вас прав выясняйте без меня.

Мне не везёт с "dbForge Studio" у меня он падает в случайные моменты времени. Версия для MS SQL сервера на порядок стабильней версии для ORACLE SQL, но тем не менее тоже падает. конечно не проблема обратно открыть 10 окошек, но вымораживает.

Два простых примера — простейший рефакторинг — переименовать переменную — переименовывает во всём документе, до и после DECLARE этой переменной, то есть переименовывает там где заведомо делать этого не надо, при этом если вызвать переименование не на DECLARE, а просто в коде то как раз про DECLARE dbForge забудет.
Второе — а) генерация тестового набора данных( описано в статье ) — не генерил значение внешнего ключа, пришлось руками доделывать, б) при наборе записей больше 16 000 скрипт вставки данных превращался в венегрет, который конечно можно было распутать, но желания нет, в) Если задать генерацию справочника ( 10 записей ) и данных ( 10 000 записей ), то генерил данных ровно столько же сколько записей в справочнике, вместо 10 000 записей в таблице данных, всего 10.

"dbForge Studio" несомненно отличный продукт, если знать где раскиданы грабли.

Единственное что в нём отлично работает это форматировщик, у которого очень гибкие настройки, но и его порой заставить работать без бубна не получается.
на мой вкус dbForge — сырой продукт. и спорить с вами о вкусах я не буду.

Да в этом риск, что хакеры натворят делов, поэтому если система для внутреннего пользования и "не крупная" ( не больше 200 — 500 пользователей ) то доступ можно спокойно дать.
Пользователи всегда заинтересованы в скорейшем выполнении своей заявки, техподдержка без дела не сидит и любая самая пустячная заявка которая может подождать неделю — эту неделю ждать и будет. Поэтому если у пользователя есть способ своими руками сделать быстрее, то он сделает и часто пользователи не сообщают о системных ошибках которые исправляются за пару минут, потому что им дольше техподдержке объяснять в чём дело, чем исправить.

Если клиенты пользуются сервисом в качестве облачного, то такой способ хранения формул просто облегчает работу программиста — нет необходимости иметь отдельную хранимую процедуру под каждого пользователя.
При ошибке в формуле, отчёт не построиться или если будет адекватная обработка ошибок, то отдельные формулы не будут вычислены.

Основная идея — упрощение сопровождения.
Написать движок который строит произвольную таблицу не трудно, я подобный для веба уже писал .

Сегодня начал писать примитивную реализацию своей идеи, думаю к 10 марта допишу, будет время прикручу вывод отчёта на вебе.

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

Просто часто по работе изучая "best practices" я часто на Хабре находил отличные решения, поэтому почему бы не поделиться? Если кому то пригодиться я буду рад.

Сейчас 4 дня "праздников" у меня в планах реализацию запилить.