Hallo,
- MS die Treue halten und den IDC (siehe IIS - Dokumentation) verwenden
- Win32::ODBC verwenden, das ist ein PERL-Modul mit dem auch auf den SQL Server zugegriffen werden kann, wie das geht siehe bei mir "daheim"; Viele Grüße, Rolf
naja, ob das der richtige Weg ist ???
IDC <-> ASP. Da zieht IDC auf jeden Fall den kürzeren.
Ein bestehendes Intranet auf ASP-Basis durch PERL-Skripte ersetzen :-(
Aber um auf die Frage von Marcus zu antworten:
Access -> SQL Server: In Access gibt es einen Upsizing-Assistenten, der
die komplette DB inkl. aller Tabellen, View, Indizes, Constraints, ...
auf einen SQL Server überträgt und gleichzeitig alle Verbindungen
deiner Access-DB konvertiert, so daß alle Formulare weiterhin lauffähig
sind. Diese Methode ist dem Import in SQL Server durch die MMC auf jeden
Fall vorzuziehen, da hierbei schon mal größere Probleme (vor allem bei
den Constraints) auftauchen können.
SQL-Statements in deinen ASP-Seiten sind natürlich anzupassen,
besonders, wenn in den Statements Datum und Konvertierungsfunktionen
benutzt wurden (wahrscheinlich hast Du dich nicht an ANSI-ASQL gehalten,
gelle ?)
Generell kann man sagen, daß man so viel wie möglich (besonders komplexe
Abfragen) in die Datenbank verlagern sollte, da die Performance
gegenüber der Ausführung durch das ASP-Akript ungefähr dem Faktor
2-3 steigt.
Wenn Dir das aufgrund umfangreicher Parameter zu umständlich sein sollte,
kannst Du in SQL Server aber auch über T-SQL Stored Procedures
programmieren. Diese kannst Du dann mit Parametern füttern.
Einen SQL Server zu integrieren, ist an für sich nicht schwierig.
Die Zugriffsbeschänkungen hängen vor allem von der Verwendung eures
Intranets ab. Wieviele User, sehr viele unterschiedliche Datenbankberechtigungen, ...
Der Zugriffsschutz auf Datenbankebene kann entweder durch den
NT-User, der durch den Browser angemeldet wurde oder durch eigene
DB-User geregelt werden.
So, ich hoffe deine Fragen beantwortet zu haben.
Tschau, Stefan