|
Title: ADS - Analyse Unknown Member Index Post by: Heart Informatisering B.V. on May 11, 2012, 11:03:07 am Binnen Profit wordt op diverse plekken gebruik gemaakt van een FILE() commando; een commando waarmee wordt gekontroleerd of een bepaalde file fysiek op schijf aanwezig is. Zo ook om te bepalen of er indexen zijn, hoeveel, en welke.
Voor ADS geldt eigenlijk dat we dit alles aan de Advantage Database Server zouden moeten (kunnen) overlaten; als de Gebruiker rechten heeft tot de Data Dictionary op de ADS Server, zou die ADS Server (die verdere rechten heeft tot alles wat in die Data Dictionary is opgenomen) ons van de resterende informatie moeten voorzien. Helaas gaat die vlieger nog niet helemaal op. Stel dat we tabel LOVO opnemen in de ADS Database, en deze reorganiseren. LOVO heeft 14 indexen. Deze indexen hebben namen als LOVO_IN1.CDX t/m LOVO_I14.CDX, en indextags A1 t/m A14. Hoewel wij de indexen in de volgorde A1 t/m A14 opnemen in de Advantage Database, toont ADS (in vorm van de Data Architect) e.e.a. in een willekeurige volgorde. Zie bijv. de kolom met selektie van indexen in de Data Architect: (http://www.heartprofit.com/www/transfer/graphics/ads/ada120511001.PNG) waar de indexen nu getoond worden als A5, A13, A1, A11, A3, A2, A9 etc. Zouden we de tabel nogmaals reorganiseren, dan kan de volgorde best anders zijn, en, een volgorde A1 t/m A14 zal ook best wel eens voor kunnen komen. Feit is, dat dit om e.o.a. reden nooit 100% in de juiste volgorde staat. Omdat we toch niet vanuit de Data Architect zullen werken, is het daar hooguit "lastig" dat we even zullen moeten zoeken naar de gewenste index, maar, is het het belangrijkst dat alle indexen in ieder geval gekoppeld zijn; dit, opdat als we een record zouden muteren, alle ADS indexen worden aangepast. Voor Profit geldt echter dat als we het aan de Data Dictionary zouden overlaten, in bovenstaand voorbeeld A5 de 1e index is, A13 de 2e index, A1 de 3e index etc. Ofwel, als wij SET ORDER TO 1 zouden doen, en daarbij een index op Bedrijf + Verkooporder wensen te selekteren, krijgen we een kompleet andere index voor onze kiezen ! immers, de 1e index is nu A5 en bevat een totaal andere indeling. Of dit "een bug" binnen ADS is danwel of we dit op een andere formelere wijze via een ADS-API kunnen oplossen moet nog verder onderzocht worden. Vooralsnog is ook hier de oplossing dat wij vanuit Profit "scannen" welke indexfiles er zijn, en nemen we deze stuk voor stuk in de juiste volgorde (A1 t/m A14) op, zodat we met een SET ORDER TO 1 ook daadwerkelijk Tag A1 krijgen. Let op: Een gebruiker dient hiermee niet alleen rechten te hebben tot de lokatie waar de ADS Data Dictionary zich bevindt, maar ook voor de directory's die daaronder liggen! Zo zal de Data Dictionary zich (v.w.b. de Testbestanden) bijv. bevinden op \ADS_ServerADS_DATA_SHAREDATA0001HP_TEST.ADD maar bevat de "DATA0001" directory ook een indeling naar "LOLOTF", "ADADTF" etc. waar de gebruiker ook rechten toe zal moeten hebben. Ook zullen er rechten moeten zijn voor de lokatie waar de indexen zich bevinden; voor Applikatie LO bijv. op \ADS_ServerADS_INDEX_SHAREINDX0001LOLOTI. Zonder deze rechten kan Profit niet bepalen dat een ADS tabel "indexen" heeft, en kan Profit foutlopen op een melding "Unknown member Index". Nb: Overigens volgt er per heden wel een normalere melding die duidt op het niet hebben van voldoende rechten.
|