Исключить поля из запроса.

← →
sniknik © (2015-04-23 11:07) [0]

Идиотская ситуация, решения скорее всего нет... т.что тема именно "на потрепаться".
Значится есть много баз, информикс (это важно, динамического создания запроса в пакете нет, нескольких команд не позволяет... ну, вернее сервер может и позволяет но используемый ODBC драйвер даже не передает более одной команды, и другие ограничения/фичи)

Ну вот, прога работает переключаясь с одной базы на другую, структура одинаковая... теоретически, но некоторые базы "ровнее" чем другие, им самовольно/под давлением "очень надо"менеджеров/просто по глупости, добавляют/меняют поля. Что в общем привело к использованию * в запросах, и появлению в клиенте условий - если поле есть то делаем, нет пишем "отказ" вместо значения. Понятно, что плохо, но достали скандалы на тему "структура должна быть единой".
Это в общем, а теперь проблема, есть таблица у которой нельзя указать *, т.к. там есть пара не нужных в общем то программе полей с персональными типами, драйвер "валится" если такое присутствует в запросе. В общем нужно, единственное что придумал, либо указать исключение - SELECT * EXEPT(поле3, поле4) FROM ..., либо указывать с учетом если есть - SELECT IFEXISTS(поле1), IFEXISTS(поле2) FROM ...

В общем если кто-то вдруг знает/сможет придумать как сделать такой запрос на информиксе... плиз. Нужен именно запрос, другие методы не предлагать (по другому и так знаю как решить - административно, требуется грамотный "жосткий" руководитель + пара тройка увольнений...), формировать запрос с клиента опираясь на схемы тоже ... не это то как раз сработает, но это жуткое усложнение логики, переделка всей цепочки и обработок, запрос один из, а переделывать нужно все на сервере, это не на клиенте не показывать если поле отсутствует, не пойдут на это, да и вредно узаконивать "чтобы любой идиот мог воротить со структурой все что пожелает".

p.s. В итоге оно все устаканивается конечно, все приводится к единой/стандартной структуре, до следующего раза... а вся эта "байда" с решением нужна только для того чтобы "не быть крайним", чтобы менеджеры между собой решали "отказ в данных" по каким-то полям, а не писали в IT панические письма - "программа глючит".

← →
junglecat © (2015-04-23 12:35) [1]

а через вьюху это не провернуть?

← →
sniknik © (2015-04-23 13:29) [2]

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

← →
Труп Васи Доброго © (2015-04-23 13:35) [3]

> но это жуткое усложнение логики, переделка всей цепочки
> и обработок

Раз уж у тебя в клиенте уже есть
> если поле есть то делаем, нет пишем "отказ" вместо значения.

то что мешает развить это решение дальше? Ты же заранее знаешь в каких базах присутствуют "левые" поля и знаешь названия этих полей? Сделай массив запросов и список баз, которым они соответствуют и применяй в разнящихся местах те запросы, которые подходят именно к этой базе.
Это добавит всего один дополнительный запрос, перед выполнением рабочего запроса.
Что-то типа select zapros_n from supertable where base_ID=ID
,где superbase это единая таблица на "суперсервере" где хранятся тексты запросов для каждой базы, zapros_n это N-тый запрос (их же "разных" может быть несколько для одной базы). И всё. По имени базы получишь необходимый текст Selectа и выполнишь его. И логику менять особо не надо :)

← →
Ega23 © (2015-04-23 13:49) [4]

> то что мешает развить это решение дальше? Ты же заранее
> знаешь в каких базах присутствуют "левые" поля и знаешь
> названия этих полей? Сделай массив запросов и список баз,
> которым они соответствуют и применяй в разнящихся местах
> те запросы, которые подходят именно к этой базе.

Если я правильно понял Николая, то:
1. Проблема в "персональном" типе столбца, a-la uniqueidentifier в MSSQL или macaddr в Postgres, от которых стандартный ODBC-драйвер приходит в изумление и отказывается понимать.
2. Структура баз "на местах" меняется, иногда, но меняется, как это отследить в плане массива - не понятно. Это если забыть о геморрое в плане изменения этого массива, при большом количестве клиентов и частом изменении структуры нужно вообще отдельного человека на работу брать, этакого "смотрящего" за массивом текстов запросов.

Жопская ситуация, пардон май френч. ИМХО, без административных нагибов не обойтись.

← →
Ega23 © (2015-04-23 13:53) [5]

Как вариант решения проблемы (административный):
0. Ввести единую структуру БД.
1. Под страхом обряда единения с деревом (посажения на кол) запретить менять эту структуру всем, кроме Главного.
2. Если кому-то там надо какие-то хитромудрые поля с замороченными типами данных всенепременно добавить, то разрешить создавать дополнительные таблицы со связью один к одному, и вот в них уже резвиться так, как хочется. Хуч порноролик в блобе к каждой записи хранить.

← →
sniknik © (2015-04-23 14:06) [6]

> Ты же заранее знаешь в каких базах присутствуют "левые" поля и знаешь названия этих полей?
Откуда? Я знаю только "костяк"(/стантарт/то что должно быть а не то, что стало после того как комуто "приспичило") на который опираются запросы. Если что-то добавится/поменяется это "сюрпирииииз".

> Сделай массив запросов и список баз
эээ... большой список получится, боюсь это к решаемой проблеме только добавит другую, путаницу в нем (+ нужно разрабатывать правила как зависимые и формируемые от результатов запросы записывать), но никак не решит основную.

← →
sniknik © (2015-04-23 14:15) [7]

> 1. Проблема в "персональном" типе столбца, a-la uniqueidentifier в MSSQL или macaddr в Postgres, от которых стандартный ODBC-драйвер приходит в изумление и отказывается понимать.
Типа того, в вольном переводе что-то типа SET of SET of record. В наборе(перечислении) наборов хранятся записи из нескольких параметров (INT, Char еще что-то ). SET - произвольное количество однотипных данных, record - одна запись из строгого количества нескольких разнотипных.

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

← →
sniknik © (2015-04-23 14:19) [8]

> 0. Ввести единую структуру БД.
Блин, она есть, и правило "менять нельзя" тоже есть, но кому легче от этого когда "почему ваша прога постоянно глючит?".
Причем реально ни одного глюка, именно проги, зарегистрировано не было. Но... "ложечки нашлись, но осадочек остался" © анекдот.

← →
Труп Васи Доброго © (2015-04-23 14:28) [9]

> Я знаю только "костяк"

ЖП-ситуация.

> Если что-то добавится/поменяется это "сюрпирииииз".

Административно обязать уведомлять об изменении структуры нельзя?

> большой список получится

Так уж и большой? Пусть филиалов есть 20, но в 18 структура то осталась стандартная, а только в двух работают "умники", значит всего три записи будет: одна для 18ти филиалов и по одной для умников.

← →
Дмитрий С © (2015-04-23 14:39) [10]

А если получать сначала структуру таблицы, а потом формировать запрос?

← →
Труп Васи Доброго © (2015-04-23 15:05) [11]

> А если получать сначала структуру таблицы, а потом формировать
> запрос?

Всё генитальное - просто! :)

← →
Ega23 © (2015-04-23 15:10) [12]

> Блин, она есть, и правило "менять нельзя" тоже есть, но кому легче от этого когда "почему ваша прога постоянно глючит?".

Штрафовать мерзавцев. Рублём. Если так сильно надо свои дополнительные поля - пусть создают дополнительную таблицу, связывают её жестко по ID (с delete cascade) и там хреначат любые SET-ы.

Это как попытка защиты базы от админа с правами superuser. Вне административного ресурса - не решается.

← →
Ega23 © (2015-04-23 15:11) [13]

> А если получать сначала структуру таблицы, а потом формировать
> запрос?

Тащемта это северный пушной зверь семейства псовых например.

← →
sniknik © (2015-04-23 15:39) [14]

> А если получать сначала структуру таблицы, а потом формировать запрос?
Из [0]
> формировать запрос с клиента опираясь на схемы тоже ... не это то как раз сработает, но это жуткое усложнение логики, переделка всей цепочки и обработок, запрос один из, а переделывать нужно все на сервере, это не на клиенте не показывать если поле отсутствует, не пойдут на это, да и вредно узаконивать "чтобы любой идиот мог воротить со структурой все что пожелает".

← →
sniknik © (2015-04-23 15:47) [15]

> Штрафовать мерзавцев. Рублём.
Я за! Только нужен нормальный, грамотный руководитель, а не "Ну, там, в общем вот..., очень нужно было. Ребята, а что мы можем сделать чтобы разрешить ситуацию?". И каждый раз "бой" с доказательствами, а следующий раз будто и не было, говоришь через неделю "ну мы же все недавно обсуждали, решили, нельзя! В очередной раз.", в ответ глупость какая нибудь, например "ну, мы думали раз это другая база/таблица/поле (неважно что) то можно". и опять доказывай, что общая обработка не понимает "это тоже самое но немножко другое".

← →
Дмитрий С © (2015-04-23 17:59) [16]

Ещё вариант: создать отсутствующие поля в таблицах перед запуском.

← →
кгшзх © (2015-04-23 20:21) [17]

есть таблица у которой нельзя указать *, т.к. там есть пара не нужных в общем то программе полей с персональными типами, драйвер "валится"

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

← →
Ega23 © (2015-04-23 20:30) [18]

ИМХО, * вообще только для дебага можно использовать. Ну или внутри count

← →
кгшзх © (2015-04-23 20:35) [19]

предания старины глубокой или теологическое учение?

← →
Ega23 © (2015-04-23 20:58) [20]

> предания старины глубокой или теологическое учение?

Просто выводы из практики. Запросы, когда нужно всё выбрать, встречаются крайне редко. Всегда либо только часть данных, либо вообще связку из нескольких таблиц. А звёздочка - это когда "по-бырому глянуть, чё там за фигня с id=98235465"

← →
кгшзх © (2015-04-23 21:04) [21]

Запросы, когда нужно всё выбрать, встречаются крайне редко.

нахренаж такие таблицы проектировать, данные в которых (горизонтально) нужны крайне редко?

а источник настоящей проблемы - он в заголовке темы.
проблема не в самой звезде, а в том, что драйвер не понимает все разнообразие типов данных полей сервера.

от такого драйвера нужно избавляться в первую очередь.

← →
Ega23 © (2015-04-23 21:52) [22]

> нахренаж такие таблицы проектировать, данные в которых (горизонтально)
> нужны крайне редко?

Имелось ввиду - все сразу.

← →
sniknik © (2015-04-24 10:10) [23]

> Ещё вариант: создать отсутствующие поля в таблицах перед запуском.
Во первых у программы нет прав кроме как на чтение, в исключительных случаях на запись, никогда на изменение структуры.
Специально нету. Несколько раз спасало от исинуаций "это не мы, это она сама"... вообще права как раз региональные и выдают... база-данные считаются их собственностью.

> что драйвер не понимает все разнообразие типов данных полей сервера.
Драйвер заметь, родной, пришедший с купленным сервером. Есть другой, сторонний, еще хуже, этот даже схем не поддерживает, т.е. захочешь структуру получить и не получится. И еще линуксовый, для PhP используют, тоже не поддерживает, и вообще не видел кто это делает кроме используемого у нас "Sql Explorer" и то при настройке на "прямое подключение" с использованием API.

> от такого драйвера нужно избавляться в первую очередь.
Альтернативы просто нет... есть вариант избавится от самого информикса в пользу MSSQL, но это дело далекого будущего.

> предания старины глубокой или теологическое учение?
Вообще, * действительно не рекомендуется, по разным причинам, одна из них - лишние действия сервера который в этом случае предварительно лезет в системные таблицы за списком полей.

← →
sniknik © (2015-04-24 10:18) [24]

> Во первых
Блин, во вторых забыл... вот были бы права, создал, работаешь, месяц к примеру после паника от бухгалтерии "сверка не сходится!". И все потому что поле было переименовано, а программа создала свои и пошла все считать заново, а там зависимости, накопительные суммы...
Кому после разгребать как думаешь?
Нет уж лучше сразу ошибку и скандал, раз уж не получается показать "отказ в данных" без скандала.

← →
Дмитрий С © (2015-04-24 11:25) [25]

Не завидная ситуация, конечно.

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

Query := "SELECT " + SqlIdent(SOMEFILED1) + ", " + SqlIdent(SOMEFILED2) + " FROM ..."
или
Query := SqlIdents("SELECT {SOMEFIELD1}, {SOMFIELD2} FROM ..."); // в этом случае подстановку делать.

← →
кгшзх © (2015-04-24 13:16) [26]

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

во времена семерки mssql и D2 такими полями были уникальные идентификаторы если таблицу вставляли в репликацию слиянием и делал это сам сервер.

← →
Dennis I. Komarov © (2015-04-24 13:50) [27]

Настаиваю на применении обряда Олега, или к муравьям - они уже проснулись

← →
Сергей Суровцев © (2015-04-24 15:55) [28]

>sniknik © (23.04.15 11:07)
>Значится есть много баз, информикс (это важно, динамического создания запроса в пакете нет).

В смысле? Невозможно подготовить строку чтобы отправить ее на сервер?

>sniknik © (23.04.15 14:15) [7]
>Типа того, в вольном переводе что-то типа SET of SET of record. В
>наборе(перечислении) наборов хранятся записи из нескольких параметров
>(INT, Char еще что-то ). SET - произвольное количество однотипных данных,
>record - одна запись из строгого количества нескольких разнотипных.
>Его не только ODBC-драйвер, я сам не понимаю что там находится, каждый
>раз приходится чуть ли мозговой штурм устраивать чтобы понять... хорошо
>что редко,и моей проге не нужно, вижу как другие парятся, и сколько
>глюков с этим полем.

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

← →
sniknik © (2015-04-24 16:07) [29]

> Еще предложение:
Не "еще", а второе, но и первое было лишним т.к. еще в [0] написал что так можно, но не желательно.

> сами-то добавляльщики как и через што его используют?
Не используют, они "выше этого". "Стратегией" занимаются, а не всякой низменной фигней. А если просто просмотреть, то в Sql Explorer-e на API все прекрасно (одной строчкой) видно, хотя по сути там структура "дерева" в поле, аналогичное xml-ному.

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

← →
кгшзх © (2015-04-24 16:30) [30]

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

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

← →
MsGuns © (2015-04-26 15:05) [31]

Select from select есть в Информиксе ?

← →
sniknik © (2015-04-26 20:24) [32]

> Select from select есть в Информиксе ?
Да есть, а чем это поможет?

← →
MsGuns © (2015-04-26 20:47) [33]

Тем, что можно "перекроить" исходный датасет в какой нужно

← →
MsGuns © (2015-04-26 20:49) [34]

Второй способ - написать "скрипт" на клиенте, в котором опрашиваются наименования и типы полей исходных таблиц, а затем конструируется собственно запрос.

← →
turbouser © (2015-04-26 20:50) [35]

> sniknik ©

К сожалению, мало информации. Первое что приходит в голову - какой-нибудь маппинг полей. Использовать * - это зло вообще обсуждению не подлежит.
Вообще, такое решается двумя путями - 1) нормальным проектированием 2) административно

← →
turbouser © (2015-04-26 21:01) [36]

> sniknik ©

Можно увидеть пример того что есть, что надо получить и почему не получается?

← →
sniknik © (2015-04-27 00:46) [37]

> Тем, что можно "перекроить" исходный датасет в какой нужно
Как? просто сдвинешь "проблему" одного селекта на внутренний

> Второй способ - написать "скрипт" на клиенте
Способ второй а ты третий предлагающий, и в [0] написано что способ нежелательный, не буду еще/и подробно объяснять, но им я воспользуюсь в последнюю очередь (перед этим есть вариант пойти рожу кое кому набить).

> Можно увидеть пример того что есть, что надо получить и почему не получается?
Все написано, и все очевидно, подробности только отвлекают, чем больше объяснений тем больше обсуждение сворачивает на "вы все неправильно делаете" с выискиванием не стыковок в разных описаниях.
Вот из [0]
> либо указать исключение - SELECT * EXEPT(поле3, поле4) FROM ..., либо указывать с учетом если есть - SELECT IFEXISTS(поле1), IFEXISTS(поле2) FROM ...
Поля 1 и 2 нужны, если они есть, 3 и 4 не нужны всегда. Перечисление невозможно, т.к. клиент не знает о существующем, измененном наборе, и он может быть разный в зависимости от подключения, причем переключается клиент, а работает сервер, с единой обработкой... понятнее? Вряд ли, говорил же. Просто поверь на слово, в логику работы/формирования запроса лезть НЕ ЖЕЛАТЕЛЬНО. Запрос поменять можно.

← →
sniknik © (2015-04-27 00:53) [38]

> Использовать * - это зло вообще обсуждению не подлежит.
Зло это "слепой фанатизм" к чему бы не было. А * порой спасает нервы целого отдела. Значит добро, раз спасает... ну в этом, конкретном случае.

> Вообще, такое решается двумя путями - 1) нормальным проектированием 2) административно
Спасибо КЭП. Что бы без тебя делали... а так вот пришел, и всем понятно очевидные вещи разъяснил. :)

> Использовать * - это зло вообще обсуждению не подлежит.

Так фик ли тогда мы тут мусолим вопрос как выбирать не все поля, но так чтобы любимая звезда осталась?

> но так чтобы любимая звезда осталась?
Не не не, звезда не самоцель, не нужно сводить к этому.
Меня бы устроило и формирование запроса в самом запросе (как можно в MSSQL) например, т.е. в пакете команд собрал строку и выполнил через exec. И какая нибудь тайная команда инфирмикса которая наверняка есть "унутри", ведь как то он собирает список для *, не каждый раз кучу действий выполняет, скорее все сведено в функцию... а раз есть функция то у нее возможно есть параметры "на исключение".

Т.е. средства в принципе не важны, если они в запросе, на сервере, без привлечения "клиента", главное как то либо получить все кроме пары, либо перечислить все с указанием, что чего-то нет... то чего нет в условиях/обьединениях/... не участвует, группировок нет, условие на отбор да сложное но никоим боком "звездного" списка не касается.

> с указанием, что чего-то нет
возможно нет.

> либо перечислить все с указанием, что чего-то нет

видится единственный возможный вариант: сделать запрос к syscolumns, а потом слепить запрос из полученных полей.

> [43] Inovet © (27.04.15 10:56)

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

> это только лишний раз подчеркивает, что других вариантов нет.
На 98% был уверен, еще когда писал... но "а вдруг?".

Там вот еще
MsGuns © (26.04.15 15:05) [31]
MsGuns © (26.04.15 20:47) [33]
какую то хитрость хочет предложить...

Главное не стал бы городить пакета на составление строки динамического запроса "а ля MSSQL". Т.к. повторю, проходит единственная команда, вложенные селекты есть, но насколько сложные пройдут не знаю, нужно будет проверять.
С пакетами не понятно, через драйвер ошибка -
[Informix][Informix ODBC Driver][Informix]Cannot use a select or any of the database statements in a multi-query prepare
а в используемом DB эксплогере то же самое проходит, толи он сам разбирает и выполняет по командно, то ли это ограничение в драйвере, а сервер позволяет... в любом случае - для меня пакеты не доступны.

> Там вот еще
> MsGuns © (26.04.15 15:05) [31]
> MsGuns © (26.04.15 20:47) [33]
> какую то хитрость хочет предложить...

примерно тоже самое я предлагал еще в [1].
Но это все бессмысленно, пока ты не знаешь, какие поля есть в исходной таблице или какие хочешь получить

> пока ты не знаешь, какие поля есть в исходной таблице или какие хочешь получить
Я их не знаю на клиенте, и не хочу знать, логику сильно переделывать придется, на сервере не проблема все отсюда -
SELECT colname FROM syscolumns
WHERE tabid IN (SELECT tabid FROM systables WHERE tabname="agents") AND colno NOT IN (3,4)

Вместо вюьшки в запрос твое из [1] можно переделать?
Я просто понял так, что ты предлагал обращаться к вьюшке вместо таблицы, а ее в каждой базе написать с персонализированным набором полей. Что не пойдет, поля поменяли вьюшку нет, вьюшку удалили, прав не дали и т.д. проблем станет больше.
Если не это то как?

если не это, то select from select

> SELECT colname FROM syscolumns
> WHERE tabid IN (SELECT tabid FROM systables WHERE tabname="agents")

SELECT colname FROM syscolumns
JOIN systables on syscolumns.tabid = systables.tabid
WHERE tabname="agents"

проблема именно в AND colno NOT IN (3,4)?

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

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

А вообще, интересно, какие способы вы используете для сохранения работоспособности программы в следующих случаях:
1. Пользователь отредактировал исполняемый файл в текстовом редакторе.
2. Пользователь уронил системный блок с десятого этажа.
3. Администратор разбил сервер молотком.
Это из наболевшего, а можно еще варианты придумать. :)

> Это из наболевшего

реально были 2-й и 3-й пункты?

junglecat © (27.04.15 12:35) [51]

Там смайлик, но вообще ситуация то сродни. Кто-то что-то испортил, но при этом все должно работать. :)

> Кто-то что-то испортил, но при этом все должно работать

ну это из серии "тыжпрограммист!"

> Соберите с эталонной базы ...
Страшную вещь скажу - эталонной нет. Есть основная, рабочая внутри компании, которую можно признать эталонной. НО, изменить могут и в ней, наши "теологи БД" хоть и ближе региональных, но по другим качествам от них не отличаются.

> интересно, какие способы вы используете для
Такого не было, но было не менее эпичное -
- Мы "продали" программу, а у клиента она периодически не работает! Исправьте!
- Не можем. Клиент нерегулярно платит за интернет, его провайдер за неуплату отключает, а у нас инет обязателен для работы (к серверу через инет).
- Чего? Вы мне тут мозг не парьте своими терминами. Повторяю, клиент "КУПИЛ!", программу, она ДОЛЖНА! работать.

Было бы смешно, разово на собрании, если бы это потом не вынесли официально в список проблем к устранению, прошло кучу "технических специалистов".

+
> 1. Пользователь отредактировал исполняемый файл в текстовом редакторе.
Есть шаблоны отчетов в rtf, есть рекомендации к их изменению, и пользователь который переименовал скрин в png дав ему расширение rtf... само собой программа начала "валится" (ошибку не соответствия форматов выдавать).
Проблем в принципе не было, просто объяснили что rtf это формат, а не расширение, и если хочется "картинку как есть" то ее все равно нужно вкладывать в файл нужного формата.

++
> 3. Администратор разбил сервер молотком.
Администратора уволили без зарплаты... он забрал с собой сертификаты, и начал переводить деньги ангента себе на счет, строго "до недоданого по зарплате" (честным был видать).

Подняли вопрос о "взломе программы", на полном серьезе обсуждали "как бы так защититься от админа с сертификатами паролями к ним и т.д", т.е. о того кто все получал, настраивал, пароли придумывал...
О том, что прописанная процедура дискредитации с выпуском нового не была проведена (обязательна в некоторых случаях, смена админа один из них)... не то чтобы умолчали но "у нас админа нет больше, кто все те страшные вещи о которых вы говорите делать будет?". Агенту деньги вернули за счет компании, БЛИН, по причине "недостаточно защиты в программе позволяющей махинации".

> ну это из серии "тыжпрограммист!"
скорее "яжпрограммист!" и сделаю так чтобы ко мне не цеплялись больше... хотя бы по этому поводу. :)

Ищи аналогии в более понятных вещах, например сотовый телефон и неуплата,
или там электричество с перебоями.

Исключить поля из запроса. Найти похожие ветки