Andrew Hendrickson asks:
>What are you using for the database back end and interface for the form
>above? I'd be interested in using similar facilities on my server as well.
Some development details:
server hardware: Dell OptiPlex 560/L (60 MHz Pentium, 16MB RAM, 1 GB HD)
Server OS: Microsoft Windows 95
http server software: O'Reilly and Associates WebSite Professional
Database native format: Microsoft Access (Microsoft Office Professional for
Database Engine: Custom Microsoft Visual Basic program; employs
the VB "Jet" database engine feature of VB 4.0 Pro
Last year, I was approached by Vermont EPSCoR to help develop a WWW
accessable database. They had subcontracted some third party to design the
actual database; this contracter selected Microsoft Access (Win3.1) as the
I had already developed some small expertise in this area constructing a
FileMaker Pro v2.1 Macintosh database for the folk music CD collection
which I curate at WRUV. This database lived for a short time on my old
Quadra 900, and was serviced by MacHTTP and a custom AppleScript interface.
It was slow as my 17 pound cow-cat, Fred (ok, so he brought home 3
chipmunks this week, but we think he orders out).
Since I had just received a new Pentium box and was testing Windows 95, I
figured I'd go whole hog and ordered WebSite 1.0 (Standard), Microsoft
Office (Pro), and Visual Basic (Pro) and see what I could hammer out.
Website features a special Windows API and come with some Visual Basic
"glue" to facilitate CGI-style programming in that language. Once I learned
a few things about Object Oriented programming, code development time was
less than a few days.
I have since migrated the WRUV database to the same environment; however,
now that I have a powerful new PowerPC, FileMaker Pro 3, WebStar 1.3, and
the Frontier scripting product, I will be revisiting that environment.
Enter the CIT Problem database. I recently upgraded my Win95 web product to
WebSite Professional. Bundled with WebSite Professional is Allaire's Cold
Fusion Standard (and a card good for a special offer to upgrade to Cold
Fusion Professional). Cold Fusion acts as a WebSite DLL, promising a high
performance interface to ODBC compliant databases. Through the use of
simple four or five line templates, WebSite users can develop quick and
easy WWW database interfaces.
Sure enough, only took two or three hours between cracking open the WebSite
manual to the Cold Fusion chapters and having a simple DBF database with a
web data entry interface.
Problem was, it took another day and a half to write a query interface,
realize it wouldn't work because there was no elegant way to account for
missing or NULL fields, search the Allaire and O'Reilly Websites for
additional documentation, find the documentation, find a Cold Fusion
language construct that would solve the problem, and then discover that
that language construct was not supported in Cold Fusion Standard.
So yesterday I migrated back to an Access MDB file and custom VB interface.
About 4 hours, I'd say, to transparently replace the problem entry
interface and offer the query capability. Today, maybe I'll write an Update
procedure. Monday, look for some VB SMTP mail routines.
| Wesley Alan Wright <[log in to unmask]>;http://mole.uvm.edu/~waw/|
| Academic Computing Services * __0__ * * |
| Room 238 Waterman Building / \ | \ * * |
| University of Vermont * \77 http://mole.uvm.edu/skivt-l|
| Burlington, Vermont 05405-0160 \\ *
| U.S.A. Voice: (802) 656-1254 * vv * |
| FAX: (802) 656-8148 This message copyright 1996 WAW & UVM |