BerndF
18-03-03, 08:59
Hallo Alois,
habe den Eintrag hier gelesen. wir haben dieses problem wie folgt gelöst:
as400-seite
-----------
diverse querys und sql's, die die daten aus dem pps verdichten. gestartet wird das ganze über ein cl im job-sheduler. die daten werden in einer separaten datenbib abgestellt. dieser schritt ist aber nur dann notwendig, wenn man nicht direkt auf die daten des pps zugreifen kann.
Server-Seite
------------
wir setzen MS-SQL 2000 ein. ist aber unerheblich. die vorgehensweise funktioniert auch mit oracle und mysql. dort läuft ein access-progrämmchen, dass nichts anderes tut, als die daten von der as400 in eine externe datenbank zu schaufeln. das ganze wird bei uns über den nt-sheduler automatisch gesteuert. wenn der access-job abgearbeitet ist, wird ein merker auf der as400 und auf dem sql-server gesetzt. dieser merker machts nichts anderes als der as400 zu sagen: "lösche die datenbib, um speicherplatz nach der übernahme wieder freizugeben" (muß aber nicht unbedingt sein). und für den sql-server bedeutet dies: "jetzt kannste loslegen und die importierten daten in den würfel (cube, datawarehouse) einbauen.
noch eine bemerkung zum access
------------------------------
wir setzen den odbc-treiber von walldata und nicht client access ein. client access frist zuviel resourcen. jeden falls ist das unsere erfahrung. es geht aber auch mit dem odbc von client access (nur nicht so stabil - weiß der geier warum). für den sql-server bringt access respektive windows genügen treiber mit. kann man sich aber auch aus dem netzt runtersaugen.
zeitverhalten
-------------
auf der as400 läuft der job nachts. morgens in aller frühe (5 uhr) werden die daten rübergeschaufelt und anschließend vom sql bearbeitet. das ganze läuft so ca. eine stunde. datenvolumen auf dem sql ca. 1GB was hin und her geschaufelt wird. unsere as400 ist leider nur ne 270, zeigt aber, dass auch mit kleineren maschinen eine gute performance erreicht werden.
schlussbetrachtung
------------------
dies ist wohl nicht der intelligenteste weg daten von einem system auf das andere zu schaufeln. wir haben uns nur gedacht, möglichst effizient und schnell zu einer lösung zu kommen. im nachhinein betrachtet würde ich es immer wieder so tun. warum? weil es absolut stabil und sicher läuft. null probleme.
gruß bernd
habe den Eintrag hier gelesen. wir haben dieses problem wie folgt gelöst:
as400-seite
-----------
diverse querys und sql's, die die daten aus dem pps verdichten. gestartet wird das ganze über ein cl im job-sheduler. die daten werden in einer separaten datenbib abgestellt. dieser schritt ist aber nur dann notwendig, wenn man nicht direkt auf die daten des pps zugreifen kann.
Server-Seite
------------
wir setzen MS-SQL 2000 ein. ist aber unerheblich. die vorgehensweise funktioniert auch mit oracle und mysql. dort läuft ein access-progrämmchen, dass nichts anderes tut, als die daten von der as400 in eine externe datenbank zu schaufeln. das ganze wird bei uns über den nt-sheduler automatisch gesteuert. wenn der access-job abgearbeitet ist, wird ein merker auf der as400 und auf dem sql-server gesetzt. dieser merker machts nichts anderes als der as400 zu sagen: "lösche die datenbib, um speicherplatz nach der übernahme wieder freizugeben" (muß aber nicht unbedingt sein). und für den sql-server bedeutet dies: "jetzt kannste loslegen und die importierten daten in den würfel (cube, datawarehouse) einbauen.
noch eine bemerkung zum access
------------------------------
wir setzen den odbc-treiber von walldata und nicht client access ein. client access frist zuviel resourcen. jeden falls ist das unsere erfahrung. es geht aber auch mit dem odbc von client access (nur nicht so stabil - weiß der geier warum). für den sql-server bringt access respektive windows genügen treiber mit. kann man sich aber auch aus dem netzt runtersaugen.
zeitverhalten
-------------
auf der as400 läuft der job nachts. morgens in aller frühe (5 uhr) werden die daten rübergeschaufelt und anschließend vom sql bearbeitet. das ganze läuft so ca. eine stunde. datenvolumen auf dem sql ca. 1GB was hin und her geschaufelt wird. unsere as400 ist leider nur ne 270, zeigt aber, dass auch mit kleineren maschinen eine gute performance erreicht werden.
schlussbetrachtung
------------------
dies ist wohl nicht der intelligenteste weg daten von einem system auf das andere zu schaufeln. wir haben uns nur gedacht, möglichst effizient und schnell zu einer lösung zu kommen. im nachhinein betrachtet würde ich es immer wieder so tun. warum? weil es absolut stabil und sicher läuft. null probleme.
gruß bernd