Тема: Створення в Access простої СРМ

Вітаю.
Пробую створити СРМ в Access виключно за допомгою ШІ Grok. Зараз в куті.
Маю 3 таблиці Клієнти, Контакти, Дзвінки.
Маю форму з фільтрами та вибірку у підформу у вигляді таблиці.
Саме питання - що саме треба зробити, щоб при двойному кліку на полі Результат_дзвінка, щоб відкрилася інша форма, для фіксування нового дзвінка вибраному Клієнту.

2

Re: Створення в Access простої СРМ

Клікати буду в полі самої підформи. Підформа в режимі таблиці (Datasheet) (бо там можна міняти ширину стовпчиків мишкою)

3

Re: Створення в Access простої СРМ

Не факт, що Access таке вміє. Раджу поки що не ускладнювати собі життя, і зробити окрему кнопку під табличкою, яка стає активною після вибору рядка в таблиці. Колись пізніше повернетесь до цієї форми і переробите.

4

Re: Створення в Access простої СРМ

Там є ще й перелік інших серзойних недоліків. Якщо це суто навчальний проект і викладач поставив саме вимогу використовувати MS Access, тоді (може) окей. Інакше варто обрати якусь "справжню" базу типу PostgreSQL або MySQL (чи іншу RDBMS).

тиць
чат ґпт написав:

Microsoft Access має кілька недоліків у порівнянні з сучасними СУБД, такими як PostgreSQL або MySQL: 

1. **Масштабованість і продуктивність** – Access призначений для невеликих застосунків і погано справляється з великими наборами даних (мільйони записів) або численними одночасними користувачами. PostgreSQL та MySQL ефективно обробляють значно більші навантаження. 

2. **Підтримка багатокористувацького режиму та конкурентність** – Access не справляється з великою кількістю користувачів, що може призводити до пошкодження бази даних або низької продуктивності. Сучасні СУБД підтримують сотні або навіть тисячі одночасних підключень. 

3. **Обмежена безпека** – Access має слабкі засоби безпеки, покладаючись переважно на автентифікацію Windows і простий захист паролем. PostgreSQL і MySQL пропонують розширені механізми керування доступом, шифрування та безпеку рівня підприємства. 

4. **Відсутність справжньої клієнт-серверної архітектури** – Access є файловою базою даних, що означає, що кожен користувач відкриває і редагує той самий файл бази даних, що може призводити до її пошкодження та неефективності. Сучасні СУБД використовують надійну модель клієнт-сервер. 

5. **Відсутність розширених можливостей** – Access не підтримує потужні функції, такі як збережені процедури, тригери, реплікацію, розширене індексування та повнотекстовий пошук, які доступні в PostgreSQL і MySQL. 

6. **Обмежена кросплатформенність** – Access працює лише в середовищі Windows, тоді як PostgreSQL і MySQL підтримують різні операційні системи, включаючи Linux і macOS. 

7. **Погана інтеграція з веб- та хмарними застосунками** – Access не розрахований на веб-застосунки, тоді як PostgreSQL і MySQL широко використовуються в хмарних і веб-середовищах. 

Для невеликих проектів із одним користувачем Access може бути зручним, але якщо потрібна продуктивність, масштабованість і надійність, то сучасна СУБД буде набагато кращим вибором.

5

Re: Створення в Access простої СРМ

Я в Аксессі, не те шо нуль, а загалом - мінус.

Torbins написав:

Не факт, що Access таке вміє. Раджу поки що не ускладнювати собі життя, і зробити окрему кнопку під табличкою, яка стає активною після вибору рядка в таблиці. Колись пізніше повернетесь до цієї форми і переробите.

а якщо на комбінацію клавіш, можливо?

Там є ще й перелік інших серзойних недоліків. Якщо це суто навчальний проект і викладач поставив саме вимогу використовувати MS Access, тоді (може) окей. Інакше варто обрати якусь "справжню" базу типу PostgreSQL або MySQL (чи іншу RDBMS). - розумію. Але, працюю в страхуванні, зазначена база це для мене наступний етап після ведення прозвонів в екселевського файліку. Поки коритсуватись буду я. Модливо буде до 20 000 Клієнтів (зараз трохі більше 2000). Я не програміст, думав що ШІ Ґрок зможе допомогти в питанні. Загалом план був такий: Таблиця Клієнти - цікаві для обзвона, вношу через імпорт, беру в інтернеті. Таблиця Контакти - вношу руками, буде потрібна вигрузка Контактів з Аксесса, для імпорту в гугл контакти. Таблиця Дзвінки - вношу руками, буде потрібна вигрузка дзвінків з Аксесса, для імпорту в гугл календар. налаштування через макроси нагадувань про Клієнтів, із якими був останній контакт більше 30 днів. Якщо все буде працювати, додадуться співробітники відділу - до 20 чоловік. Стосовно вибрати нормальну СРМ і не мучатись - ніхто не буде купувати в компанії. варіант який я бачив реалізований в ЛОТУСІ, вкрай незручний (бо я буду як бухгалтер, опрацьовуючий первинну документацію).