Title: Upload tabel naar ADS Server Post by: Wouter Rijnbende on March 23, 2012, 03:02:05 pm In het RightClickscherm (zie ook http://ha1.heartprofit.nl/profit/index.php?topic=24183.0)
(http://www.heartprofit.com/www/transfer/graphics/ads/SYRCADS120323001.png) zien we een opsomming van de tabellen die momenteel door ADS worden afgehandeld (niets nog), en een opsomming van de tabellen die toegestaan zijn om met ADS te mogen werken. Zoals eerder uitgelegd, gaan we ADS gefaseerd invoeren, waarbij we de tabellen stuk voor stuk gaan overhevelen naar ADS, en daarmee weer andere systeemdelen gaan raken die we zullen moeten gaan testen. Om te voorkomen dat een willekeurig ADS klant tabellen gaat overzetten naar ADS, nog zonder dat wij (Heart) daar eerst zelf mee getest hebben, is het alleen toegestaan om die tabellen over te zetten op ADS waarop wij reeds een eerste kontrole hebben uitgevoerd. Een heel eenvoudige tabel om mee te beginnen is tabel "LOAG" (Artikelgroepen). Deze zal bij iedereen wel in gebruik zijn, maar bevat relatief weinig data, en raakt niet meteen het hele pakket kwa funktionaliteit (in tegenstelling tot bijv. een Relatietabel of een Artikeltabel). Via Hoofdmenu, 9-5-8-1-3, kunnen we een tabel uploaden naar de Advantage Database Server. (http://www.heartprofit.com/www/transfer/graphics/ads/SYBHBAKO120323001.png) Starten we deze procedure op vanuit de Testbestanden, dan zullen we kopieren vanuit de Testbestanden naar de Test-Data-Dictionary; starten we de procedure op vanuti de Produktiebestanden, dan kopieren we vanuit de Produktiebestanden naar de Produktie-Data-Dictionary. Vervolgens geven we aan dat het om een LO bestand gaat, en dat de tabel LOAG betreft. Daarna vervolgen we met F1. Nb: Boven in het scherm wordt bijgehouden hoeveel records er geupload zijn, en met welke (gemiddelde) snelheid dat gebeurt; als de data geupload is, zal de nieuwe ADS tabel worden gereorganiseerd. Met dat we een tabel hebben geupload naar ADS, zal vanaf dat moment het pakket herkennen dat dié tabel in de ADS Data Dictionary staat, en zal de betreffende data voortaan uit de ADS tabel worden gelezen. De VFP tabel (G:\FOX\LO\LOTF\LOAG.DBF) hebben we nu eigenlijk niet meer nodig, maar zal toch blijven bestaan. Zouden we nu opnieuw het RightClick scherm bekijken, (http://www.heartprofit.com/www/transfer/graphics/ads/SYRCADS120323003.png) dan zien we dat tabel LOAG nu door ADS wordt afgehandeld. Tsja... maar ja... hoe kontroleren we dat nu ? Gaan we naar Raadplegen Artikelgroepen, dan ziet dat er gewoon uit zoals we altijd gewend waren: (http://www.heartprofit.com/www/transfer/graphics/ads/LOAGRA120323001.png) Hoe kontroleren we nu dat de data echt in de betreffende ADS tabel terecht is gekomen? Hiervoor hebben we de Advantage Data Architect nodig. Zoals een paar regels hiervoor uitgelegd: als we een tabel uploaden naar ADS, blijft de Visual FoxPro DBF óók nog bestaan, terwijl we deze niet meer nodig hebben. In principe zouden wij de 'upload' programmatuur zodanig kunnen aanpassen dat we de VFP tabel renamen naar bijv. *.ADS; U heeft dan nog wel een backup van de VFP tabel, maar, ze kan nooit meer geraakt worden. Tóch doen we dat vooralsnog nog even niet. Reden hiervoor is omdat ADS nog in testfase is, danwel ADS voor U in testfase kan zijn. In een eerder topic is uitgelegd dat U zelf een nieuwe (lege) ADS Data Dictionary kunt aanmaken. Dat kunt U in theorie vaker doen, in welk geval U ook uw tabellen opnieuw zult willen uploaden. Het is dan niet handig als de te uploaden tabel er niet meer is. Ook daar kunnen we natuurlijk ook wel weer wat voor maken, maar voor we er erg in hebben zijn we een komplete subadministratie voor nop aan het maken. Indien U daadwerkelijke live gaat met ADS, en U (als Systeembeheerder) een tabel omzet van VFP naar ADS, dan is het een kleine moeite om deze VFP tabel zélf aanvullend even naar *.ADS te renamen. Renamen naar .ADS zou overigens enkel aan de orde zijn, om te voorkomen dat een Database Upgrade niet per ongeluk ook de structure van de oude VFP tabel gaat bijwerken; immers, zou de VFP tabel 1,5 GB aan data bevatten én de niet-meer-gebruikte-VFP-tabel tijdens de Upgrade kwa structure willen aanpassen, dan kost dit onnodig veel tijd. |