Příspěvky uživatele


< návrat zpět

Strana:  1 ... « předchozí  14 15 16 17 18 19 20 21 22   další » ... 37

OK.

3 otázky:

1) Jaký praktický význam má zjišťování velikosti objektů v excelu podle velikosti komprimovaného souboru?

2) Proč v ukázce je velikost celého souboru 6,6 MB a tento soubor obsahuje 24 listů a (změřená) velikost každého je 4,3 MB?

3) Jak vyseparování objektu z celku ovlivní velikost samotného objektu a velikost zbývající části?

Vytvoření uvedené analýzy? Přesně spíše ne (soubor je komprimován a rozměr jednotlivých prvků v souboru se dá stanovit jen obtížně)
Odhad je možný.

Potom počítejte s makrem s rozsahem v řádu tisíce řádků, spíše více.
Doba běhu u většího souboru (předpokládám, že malé nejsou moc zajímavé) v minutách i déle.

Makro v souboru bude představovat další problém, některá měření jsou destruktivní.

K napsání takového makra jsou nezbytné nadstandardní znalosti programování (vba/C#), extrémně nadstandardní znalosti excelu, včetně "power" technologií, nedokumentovaného chování objektů, ale i některých starších, dnes méně propagovaných funkcionalit. Řada potřebných znalostí se vždy vygooglit nedá (dívám se na anglické, ruské, německé a občas i jiné weby).

Výstup. Podle mých zkušeností uvedená statistika nestačí. U malých souborů je zpravidla nezajímavá, u velkých souborů je nezbytné bližší určení místa problémů. Navíc obvykle víe vadí rychlost (pomalost) než velikost.

Údržba - MS trvale excel rozvíjí. Paralelně tu máme víc verzí. Po nějakém čase bude makro minimálně nekompletní, případně chybné.

Pokud mohu soudit podle příspěvků, je zde několik jedinců, o kterých se domnívám, že při správné motivaci a dostatku času něco podobného dokáží vytvořit. Mohu i předpokládat, že některý z nich podobný nástroj někdy vytvořil. Nicméně, nástroj pro zveřejnění vyžaduje odhadem cca 3x více práce, než nástroj pro vlastní potřebu a ne každý je ochoten ho zveřejnit.

@Merlin99

Nevím, jestli s uživateli pracuji málo nebo hodně. Jen jsem došel k poznání, že podobné předefinování základních klávesových zkratek přináší více problémů než užitku.

A co pravý klik a vložit hodnoty?

Microsoft office tools:
Spreadsheet Compare

Proč ne jednoduše:

a5: =VYHLEDAT(1E+301;$F$5:$Z$5;$D$5:$Z$5)

b5: =VYHLEDAT(1E+301;$F$5:$Z$5;$E5:$Z5)

c5: =VYHLEDAT(1E+301;$F$5:$Z$5;$F5:$Z5)

Užitečná je funkce WORKDAY.INTL

3. neděle v červnu:
Vybereme poslední květnový den, sdělíme, že víkend je v po-so a neděle je pracovní, a chceme 3. "pracovní" den:
=WORKDAY.INTL(DATUM(2020;6;0);3;"1111110")
2. sobota v čevnu:
=WORKDAY.INTL(DATUM(2020;6;0);2;"1111101")
1. pondělí v červnu:
=WORKDAY.INTL(DATUM(2020;6;0);1;"0111111")
a kdyby někdo chtěl poslední sobotu v březnu:
=WORKDAY.INTL(DATUM(2020;4;1);-1;"1111101")

Pokud to má být přesné, tak, pokud se pamatuji, gregoriánský kal. má periodu 400 let.

Možná by bylo snažší použít něco, co tyto problémy nemá
(Power Query, LO Calc, ...)

Pokud se pohybuješ v uvedených letech, a vyžaduješ přesnost, tak pozor na použitý kalendář. Přechod na gregoriánsky nebyl jednotný a to ani v rámci jednoho celku.

Použití cube funkcí je v tomto případě dost pomalé.
Tabulka se neaktualizuje tak často jako vzorce a její vyhodnocení je rychlejší.

Samotná funkce ZÍSKATKONTDATA funguje zhruba 2x rychleji než případné svyhledat.

Pokud vzorce vypadají složitě, stačí si uvědomit, že v tomto případě jsou parametry funkce ZÍSKATKONTDATA texty (mimo druhého parametru). Je tedy nutné vždy vygenerovat pomocí vzorce potřebný řetězec (shodný s původním).

(=IFERROR(ZÍSKATKONTDATA("[Measures].[GA (Počet)]";KONT!$A$7;"[v_DM_DailyOrderTabularCalendar].[MonthID]";"[v_DM_DailyOrderTabularCalendar].[MonthID].&[" & ODKAZ_NA_BUŇKU & "]";"[v_DM_DailyOrderTabularProduct].[ActivationType]";"[v_DM_DailyOrderTabularProduct].[ActivationType].&[IPTV Paid]";"[v_DM_DailyOrderTabular].[OrderLoginName]";"[v_DM_DailyOrderTabular].[OrderLoginName].&[Karel Jakub]");0))

???

Pochopitelně, na obsahu buňky a typu dat záleží.

Kontingenční tabulka nevyhovuje?

Při konstrukci dotazu ho vytvořte na samostatném řádku:
= "DRIVER=...(tato část kódu je OK)...WHERE#(lf)ONR = " & Tabulka2() ""
Tady chybí spojení textu:
= "DRIVER=...(tato část kódu je OK)...WHERE#(lf)ONR = " & Tabulka2() & ""
Po zadání takového příkazu by se jako výsledek vyhodnocení měl ukázat validní sql kód. Tento není.
Spíš by tam mělo být něco jako:
= "DRIVER=...(tato část kódu je OK)...WHERE#(lf)ONR = '" & Tabulka2() & "'"

Lze použít různé přístupy.
mepexg doporučuje natáhnout celou tabulku a potom v pq ji filtrovat.

Lze ovšem také upravit sql dotaz:

(nechce se mi přepisovat obrázek, tak jen ten kousek:

let
zdroj = Obc.Query(........., "SELECT ... where = " & hodn() )

Tak potřebné je v omezené podobě excelu 2013:

Natáhněte tabulky do datového modelu, vytvořte mezi nimi relace a pak vyrobte KT.

Stačí trochu googlit:

https://chandoo.org/wp/introduction-to-excel-2013-data-model-relationships/

Pokud si vzpomínám správně, tak v excelu 2013 se to jmenovalo asi datový model. Propojení tabulek to nějak umělo.
Nepamatuji se, jestli se model musel nějak povolovat.


Strana:  1 ... « předchozí  14 15 16 17 18 19 20 21 22   další » ... 37

Uživatelské menu

Nejste přihlášen(a)
avatar\n

Menu

On-line nástroje

Formulář Faktura

Formulář Faktura IV

Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.

Aktivní diskuse