Amatér vyděsil profesionála :-)). Ale vážně: Jsem bývalý programátor-amatér a databáze jsem kdysi řešil v rámci Delphi (BDE a Paradox). Toto už na W7 nefunguje a hledal jsem jiné free řešení pro obdobnou činnost, jaká byla řešená Paradoxem (správa výkresové dokumentace). Začínal jsem od nuly jak s obsahem databáze (vlastní data), tak se znalostmi OO Base. Výsledkem je to, co jste viděl, i když celý projekt obsahuje ještě další části - evidence času a vyhodnocování časové náročnosti jednotlivých projektů atd. ale to z hlediska požadavků na Basi jsou věci, které jsem vyřešil bez maker pouze prostředky SQL.
VYSVĚTLENÍ
1)
Zelené písmo v dotazech - nevím sice, proč je zelené, ale např. "NVL" je příkaz jazyka SQL který jsem nastudoval v publikaci "PROGRAMOVÁNÍ V SQL", kterou mám v pdf odněkud staženou z netu. Celou publikaci můžu poslat, nebo někam uložit. Cituji publikaci:
FUNKCE NVL
Můžete použít funkci NVL pro převedení hodnot sloupce, obsahujícího hodnoty null, na číslo před provedením výpočtu. Je-li aritmetický výpočet proveden s hodnotou null, výsledek je null. NVL funkce může převést hodnotu null na číslo, než jsou aritmetické výpočty provedeny, aby se zabránilo výsledku null.
Bez této funkce jsem nebyl schopen dotaz sestavit tak, aby dělal to co potřebuji a Base proti zápisu nic nenamítala (kromě barevného odlišení, ale to nemusí být chyba), takže si myslím, že je to dobře. Totéž lze uvést i pro červeně zvýrazněné texty.
Funkci "OJ" doplnila sama Base - když dáte v editaci SQL dotazu přes pravé tlačítko na spojení tabulek a vyberete "edit..." dostanete tabulku Join Properties a po nastavení vlastnosti "Right join" Base doplní právě ono slůvko "OJ"
2)
Určitá nekoncepčnost v názvosloví opravdu vychází z toho, že to bylo sestavováno metodou Pokus-Omyl a v okamžiku, kdy to začalo fungovat, tak nebyla nutnost do toho šahat a hledat "mouchy" v názvosloví, protože by se mohlo stát, že to opět fungovat přestane - tedy krok zpět. Ale pokud se mi podaří makra upravit viz téma současného vlákna, tak v rámci těchto oprav upravím i názvosloví. Mnoho prvků (neviditelných za chodu formuláře) souvisí právě s problémem, že neumím přímo šáhnout do databáze ale jenom přes nějaké editační pole. Tedy pro každý přesun záznamu z tabulky do tabulky potřebuji 2 pomocné prvky. Je to určitě nevhodné a ztrácí se přehled, proto jsem otevřel tuto diskusi a chtěl bych to řešit ....
3)
Pokud se týká obsahu a počtu formulářů - databáze slouží pouze pro moji potřebu (orientace ve výkresové dokumentaci). Kusovník není v pravém smyslu kusovníkem s vazbou na technologii a cenotvorbu a ani tímto být neměl. Je to pouze databáze výkresů s možností rozpadu podsestav a hledání. Neobsahuje tedy "nevýkresové" položky (např. spojovací a jiný nakupovaný materiál) ani počty kusů. Jde mi pouze o to, abych se orientoval v tom, co jsem v rámci své činnosti OSVČ vytvořil, abych to rychle dohledal dokázal udělat seznam předávané dokumentace i s již dříve použitými podsestavami třeba z jiných projektů a nedubloval již hotové věci. Tedy z mého pohledu je to šité na míru a zcela to vyhovuje mým potřebám.
DOTAZ A PODĚKOVÁNÍ
" .... osobně bych polovinu práce přesunul do Calcu ..." V zásadě se tomu nebráním, ale s Calcem mám (kromě běžné práce typu "sečíst hodnoty ve sloupci") také nulové zkušenosti. Zkoušel jsem propojit Calc tabulku s Basi - načetla to, ale nedokázal jsem hodnoty v tabulce Calcu z prostředí Base změnit a doplnit. Nevím tedy přesně, jak "přesunout práci do Calcu" - možná by mě pomohla nějaká ukázka přímo v mém zaslaném příkladu Kusovníku - pokud můžu poprosit.
Na odkazy jsem koukal - z japonštinou nemám zkušenosti, ale jak píšete "strýček Google" si s tím poradí, tak to snad půjde. Je tam spousta příkladů, které by asi mohly obsahovat to, co hledám, takže budu postupně studovat a s výsledkem pak seznámím.
Moc děkuji za pomoc