Як перевірити чи є string серед
завдання - заповнити combobox унікальними значеннями із двох стовпців таблиці. Спочатку заповнюю унікальними значеннями з одного стовпця за допомогою SELECT DISTINCT. Далі потрібно заповнити унікальними значеннями з іншого стовпця, і при заповненні перевіряти, чи не містяться вони вже в combobox.
див. св-во TStringList.Duplicates
> Спочатку заповнюю унікальними значеннями з одного стовпця > за допомогою SELECT DISTINCT.не забудь Select distinct LTrim(RTrim(Field))
А то будуть рядки
> завдання - заповнити combobox унікальними значеннями із двох > стовпці таблиці.
Неправильне завдання – наслідок неправильної архітектури.
чим завдання неправильна, а тим більше архітектура?
> чим же завдання неправильне
Якщо правильна, то наведи аргументи на користь розміщення даних з цихдвохполіводноїтаблиці водномуUI-списку.
ні, Сергій М., справа дещо по-іншому. Jeer каже що архітектура неправильна, я прошу його свої слова обґрунтувати. Просто цікаво, як людина, яка не знає нічого про завдання, робить такі висновки.
> helluvaname (25.01.10 23:20) [6] & gt; > ні, Сергій М., справа дещо по-іншому. > Jeer каже що архітектура є неправильною, я прошу його свої > слова обґрунтувати. > Просто цікаво, як людина, яка не знає нічого про завдання > робить такі висновки. >Ця людина знає "життя". Тому і робить такі висновки. А щодо "завдання" на жаль не зберіг яскраве висловлювання Миколи aka Sniknik про відмінність питання і завдання.
> Jeer каже що архітектура неправильна, я прошу його своїслова обґрунтувати.
Приєднуюсь до Jeer. Швидше за все база кострубато спроектована.
> Просто цікаво, як людина, яка не знає нічого про завдання, робить такі висновки.
У цієї людини дуже серйозний досвід, який не проп'єш.
В принципі, я припускаю, що дана ситуація (в один комбік запису з різних таблиць пхати), хоча я відразу приклад такої ситуації придумати не можу. Але тут виникає питання: а нафіга винаходити велосипед, якщо є TDBComboBox?
Є грубе, але всім відоме контр-питання: "А на фіга козі баян?"
Ось запитує людина: "Мужики! Є у мене звичайний автомобіль, він катається туди-сюди, але мені треба щоб він боком котився. Як?"
У принципі, питання має право на існування і навіть рішення можна запропонувати і не одне, але також має право та відповідь "А ніяк. Архітектура автомобіля "неправильна" для цієї дії".
При цьому я не маю навіщо тобі це було треба, тобто. не знаю твого завдання.
Ось тепер і поясни, навіщо змішувати різні сутності (два поля) в одну (загальний список).
А якщо це одна сутність, навіщось розкидана у два поля - очевидна помилка проектування.
Ось якщо це одна сутність, але мають місце її "відтінки", то слід все ж таки залишити одне поле для сутності і ввести додаткове поле "відтінок".
при обліку накладних потрібно заносити до таблиці склад "звідки" та склад "куди". для цього потрібно два різні стовпці. щоб порахувати залишок на якомусь складі, потрібно вибрати назву складу в комбобоксі і натиснути кнопочку "порахувати". стовпець "звідки" може не містити всі унікальні записи стовпця "куди" і навпаки, тому потрібно вибрати всі унікальні записи з обох стовпців.
Для цієї мети має бути передбачений довідникскладів.
> helluvaname (26.01.10 10:52) [10] > > при обліку накладних потрібно заносити до таблиці склад "звідки" > та склад "куди".
Ну тобі й помилка проектування.
Як правильно зауважив тезка, тобі потрібно мати окрему таблицю-довідник "Склади". У ній завжди буде повний та унікальний список твоїх складів.
Залишки зазвичай вважаються не за накладними, а за станом складу(ів), що формується в момент проведення накладної. У принципі, можна і за накладними перераховувати, але ці зайві "рухи тіла" потрібні більше для верифікації та перевірки цілісності.
Для того, щоб порахувати залишок, не треба знати "Звідки", та й "куди" теж. Потрібно знати прихід і витрати.
Повинен вийти залишок 15 А вийде що. a +10 b +20 c -10
можливо, а в чому перевага?
> можливо, а в чому перевага?
Читати про нормалізацію БД.
У вас там що, назви складів змінюються раз на годину? Адже в [12] написано. Будеш мати довідник завжди під рукою. І при введенні накладних, і при розрахунках. Заповняй свої комбобокси один раз і користуйся.
У нормалізації БД. Будь-який більш-менш пристойної БД повинно бути нормалізованою.
> helluvaname (25.01.10 15:38) > > завдання - заповнити combobox унікальними значеннями із двох > стовпців таблиці. > Спочатку заповнюю унікальними значеннями з одного стовпця > за допомогою SELECT DISTINCT. > Далі потрібно заповнити унікальними значеннями іншого > стовпця, і при заповненні перевіряти, чи вони не містяться > вже в combobox. > Питання - як цю перевірку здійснювати?Не треба жодних перевірок здійснювати, SQL-сервер, як завжди партизанський,сам це зробить, кодер просто потрібно мати початкові знання SQL.
+ Інтерфейс має бути лише інтерфейсом. Вся логіка нехай буде на сервері. Що якщо завтра війна? (перейшли іншою мовою / інше)
> Вся логіка нехай буде на сервері.
Не забудь додати: "Це моя приватна думка"
ok :), imho хоча не бачу чим це може бути погано. Сервер з БД частіше переживає своїх GUI клієнтів
select distinct S.A from
> select distinct S.A from > (select Col1 як Table1 &un &select Col2 як Table1) S