>Unfortunately within an AOLserver application, your choice of db and db
>driver can impact what your code looks like. The advantage of any of the
Speed is not a big issue for us. We idle a lot. However, we want to avoid
writing code to particular vendor-supplied APIs where possible. And that
includes AOLServer database drivers, and the ns_set API. This probably
sounds utopian, but what we'd really like, if possible, is to make all major
hardware and software components into commodity items. If we don't like the
OS, we jerk it out and plug a different one in. Same goes for the web
server software, the database back-end and its drivers, and even the
scripting language. You can't just port all your code to another scripting
language overnight, but you can leave yourself options to switch to another,
and that's what we want. The rest of those pieces can be abstracted or
emulated if the .ASP's or .ADPs are built correctly to begin with. A
powerful and portable language like TCL supports that degree of abstraction.
We're sick of being locked into a platform (in our case
IIS/ASP/VBScript/ADO/MSSQL/WinNT) and don't want to make that mistake again.
However close we can come to achieving this lofty goal, I'm sure it will
yield some useful information for us and the community at large.
>If Linux is a possibility in the future, you may wish to consider using it
>now or benchmarking it. Also, another choice you may wish to look into now
Linux is a "go" as soon as I can assemble the rest of the pieces to make it
a viable platform for application/web serving. And hooking to SQL Server
for now. It looks like AOLserver or Apache+mod_dtcl will be involved. I
just try things on NT first because they're usually easier to install, and
to verify that each piece will also work on NT. Our firewall is on Linux (I
built it).
>if Linux is a future migration path is using Postgres instead of SQL
>Server. Postgres runs on both Linux and Windows, and that will also give
Postgres is a big possibility later on. I still have to give it the
shake-down, and find some developer tools for it similar to MS SQL Server
Enterprise Manager. We like that tool, at least for the moment. Any URLs
for those tools would help.
THANKS GUYS. I've collected more useful info today than my last 3 days of
research combined.
--
Mark Hubbard: [EMAIL PROTECTED]
Microsoft Certified Professional
"Knowledge is Power."
-----Original Message-----
From: Jerry Asher <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, August 22, 2001 3:52 PM
Subject: Re: installing AOL Server on WINDOWS!
>>Or the ODBC-ODBC Bridge from EasySoft.
>
>I have about three weeks experience with the ODBC-ODBC bridge, and it works
>well and seemed to work pretty simply. It's what I used when converting
>Rob's DB/2 driver into the new odbc driver.
>
>If I recall correctly, that would give you the possibilities of:
>
>Windows: AOLserver speaking ODBC to Windows ODBC Manager to SQL Server
>
>or
>
>Linux: AOLserver speaking ODBC to Linux: Easy Soft Bridge to Windows: SQL
>Server
>
>or even
>
>Linux: AOLserver speaking ODBC to Windows: Easy Soft Bridge to Windows: SQL
>Server
>
>Unfortunately within an AOLserver application, your choice of db and db
>driver can impact what your code looks like. The advantage of any of the
>above is that you will only have to debug/experience one db driver within
>AOLserver, regardless of which platform you run AOLserver on.
>
>A client of mine found that AOLserver connecting to SQL Server didn't have
>the performance they desired. And I believe that others have described
>experiences where AOLserver on Windows just didn't have the punch of
>AOLserver on *nix.
>
>If Linux is a possibility in the future, you may wish to consider using it
>now or benchmarking it. Also, another choice you may wish to look into now
>if Linux is a future migration path is using Postgres instead of SQL
>Server. Postgres runs on both Linux and Windows, and that will also give
>you more options when it comes to migrating webserver or db from one
>platform to another. You'll be able to do all sorts of stuff without
>having to worry about changing dbs, or changing your applications. I can't
>comment on which is faster for your needs: postgres or sql server.
>
>
>Jerry
>
>
>
>=====================================================
>Jerry Asher [EMAIL PROTECTED]
>1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980
>Berkeley, CA 94709 Fax: (877) 311-8688
