Yes - HTTP error messages are not very helpful - Try to look in the HTTP servers error log instead. It should be in logs/errorlog under your HTTP installation. I try to send the MIME type from WDB as early as possible, so normally error messages should be passed to the client - so you would see the WDB generated error message instead of the little helpful server error message. This could indicate that it is a very basic thing that doesn't work. - Perhaps a missing ; or " in the setup section ? or a missing include file ? - Try to simply run WDB from the command line. If it works you should see an error message like this :
Content-type: text/html
Can't open /...///.fdf: No such file or directory
- Have you configured your 'sybperl.pl' file ? ( I think the sybperl installation notes gives a hint about this somewhere ). The sybperl.pl file has defaults for $SYBASE and $DSQUERY etc. if they are not defined. It should look something like this :
$ENV{'SYBASE'} = "/usr/server/sybase" unless $ENV{'SYBASE'};
$ENV{'DSQUERY'}= "SYBASE" unless $ENV{'DSQUERY'};
You can either change the sybperl.pl file or add lines like the ones above in the beginning of the wdb script.
When the HTTP server starts a CGI script these scripts are run with a minimum environment - Not even $HOME is set ! The only environment variables set are those explicitly set by the HTTP process. If you enable debug in WDB you will see the environment used. ( set $debug = 'yes' and $debugfile = " some file" )
Read the Perl FAQ : "1.13: How do I get Perl to compile on Solaris?" You can find the Perl FAQ and other useful information at archives such as the Nexor archive (UK) http://web.nexor.co.uk/perl/perl.html, there are a few archives in the US as well, they are mentioned in the Nexor home-page.
I got in touch with Michael Peppler <mpeppler@itf.ch>, the author of
sybperl, who said *not* to use -DPACKAGE_BUG when compiling sybperl.
After I did this all the problems went away.
-- Andrew Gay <andrew@ssynth.demon.co.uk>
No - the Sybase server does not have to be on the same host. As WDB is called by the http daemon, they have to be on the same host. - And as WDB was written in sybperl - sybperl has to be on the same host too. Sybperl was written using the Sybase Open Client DB-Library, so it will be able to access any Sybase server anywhere in the net, just like any other Sybase client. The architecture is as illustrated in the following figure.
+------------+ +-------------------+ +----------------+
| WWW Client |----| HTTP Server | | |
| (Mosaic) | | (NCSA's http) | | |
| | | | | | |
| | | WDB | | Sybase server. |
| | | | | | |
| | | Sybperl | | |
| | | | | | |
| | | OpenClient DB-Lib.|----| |
+------------+ +-------------------+ +----------------+
Each machine can be of a different type : PC, NT, SUN, VAX, HP, ... but you need the Sybase OpenClient DB-Library for the machine type where you plan to use WDB, as you need it to compile Sybperl. Any WWW client will do, as long as it supports HTTP, and HTML. (But the system was designed to "look nice" on X-Mosaic)
You need Sybase OpenClient Library for the platform where you plan to run WDB. Without the OpenClient Library you will not be able to compile sybperl.
WDB was developed on UNIX, but it should be able to run on any platform where you can get Sybperl and a HTTP server to run.
The normal HTTP access restrictions can be applied to the system as a whole : Either only allow access from specific hosts, or by specific users. This can be done without changing the WDB system. For more on the Authentication mechanisms in the HTTP protocol - check :
- But if you want to support privileged access to specific rows in the database it gets a little more complicated.
For example if all but a specific user should be denied access to a specific FDF you could add
PERL = if ( $ENV{'REMOTE_USER'} ne "arnaldo" ) {
print "Bug off !!!"; # - or something more polite ! :-)
exit 1;
}
Please note that the environment variable 'REMOTE_USER' is only set if you use the NCSA httpd's access authorization to allow only specific users to access the WDB script.
Modifications are not so trivial ! Assuming you had implemented a decent authentication system, inserts and deletes would not be too bad. Updates, however, are a bit more complicated.
A normal update session would be something like
The problem is that there are no "current connection" in HTTP, and no way of telling if the user "logged out", which makes it difficult to lock rows in a reasonable way, and knowing how long you should keep the lock.
If you want to implement such a thing and use WDB as a basis - feel free to do so. If you come up with a really cool way of doing this and you would like to have it included in the standard WDB distribution I'd be happy to hear from you !
This is a bug in PC-Mosaic. The selectable options in the 'enum' field are translated into the following HTML code :
<option value="xxx"> YYYYYY
Where "YYYYYY" is the label displayed to the user, and "xxx" it the database value to search for. - the problem with PC-Mosaic is that it returns the label instead, ignoring the "value" attribute.