pedigree Pedigree Website Package
Frequently Asked Questions


Frequently Asked Questions

How do I create a link in an HTML page to a given dog's/cat's pedigree without using index numbers that change?
If you want to put a link into a web page on your web site, that when clicked, will display a pedigree of a particular animal, this is how...
        This "op=pedigree" trick works for most of the scripts (not just
How do I add my dog's/cat's photo so it appears correctly?
There are two ways to add photos to an Alfirin Database: In either case you use, the concatenation of $szPhotoDir with the sixth field MUST be a full URL to the photo for the photo to appear properly. You can upload your photos to any folder on your web site, or even on a different web site, as long as the concatenated URL is correct.
TIP: The most common mistake made here is to forget to put the final slash character on the definition of $szPhotoDir (and $szImageDir also).
Is there a way for me or other people to enter their pedigees directly into my database via the web site?
No. You can tell people to use the "" script, but this only allows them to enter the information and have it emailed to you (the database administrator). You must enter the data into your PC offline, generate completely new index files, and upload all the new files to your web site.
How do I make "" run via the web site?
On one of your HTML pages, add something like this: Of course, you must replace "" with your real web site domain name.
Do the web scripts work with MySQL, PHP, Access, or any other relational database system?
No, not at this time.
How do I add COI (Coefficient of Inbreeding) to my web site?
COI takes too much calculation time to compute online. If you tried this, you would get web server "timeouts". It is best that you calculate your COI's offline, using PC software such as Breeders Assistant or BreedMate. Have your PC software store the COI information for each dog/cat in the database, and then export it as one of the fields to the .dbw file. I recommend you piggyback COI with the DOB (Date of Birth / Whelp Date) field. This will cause the web scripts to blindly display the COI information next to every place it displays the DOB.
I notice some people have made custom modifications to their web scripts. How can I add those to my web site?
The best way to ask others about sharing their mods is to join the Alfirin Pedigree Database User's Group (APDUG) at Yahoo! Groups.
The location is .  You must get permission from the group moderator, Kristen Henry, to join.
How do I prevent 'Web Crawlers' from harvesting my web site?
I have an approach that works, but it's not perfect. Each such "harvester" has a unique "HTTP_USER_AGENT" identification that can be trapped. If you look in the file "" near the bottom, you will find some code that blocks two of them named "iCollect" and "WebCrawler", and it looks like this:
# screen out iCollect and other Web Crawlers!
$szUserBrowser = $ENV{"HTTP_USER_AGENT"};
if ($szUserBrowser =~ /iCollect/i) {
   &webCrawlersAreBogus($szUserBrowser, "iCollect");
if ($szUserBrowser =~ /WebCrawler/i) {
   &webCrawlersAreBogus($szUserBrowser, "WebCrawler");
This is where you can add "blocks" for other "harvesters" as you discover them. Look in your web server log files to know what their HTTP_USER_AGENT names are.
How do I use to restrict access to my web site?
You can configure the scripts so that users will be required to enter their email address and password in order to view pedigrees on the web site. The process works like this:
  1. Change the line in that says $nSecurity = 0 so that it reads $nSecurity = 1
  2. Now when people try to search for a pedigree, it will prompt them to sign up with their email address and a password that they choose.
  3. After they click the sign up button, an email will be sent to you, the database administrator.
  4. In the email you get, there will be instructions for what information you must add to the passwords.txt file.
  5. Then you reply to the email, which also contains a hyperlink for your user to click on.
  6. When they get the reply email, they click on the hyperlink, which downloads a "cookie" to their PC.
  7. The next time they attempt a search on your web site, their browser will provide the cookie to your web site.
  8. Assuming that the cookie is valid (they expire after a year), the user will be granted access to view pedigrees.
  9. After their cookie has expired, or if they deleted cookies, bought a new PC, reinstalled Windows, or in some other way caused the cookie to go away, they must sign up again.
How can I add custom <META> tags or JavaScript to the dynamically generated web pages?
The web scripts print out their HTTP header from a function called "emitHttpHeader" in file "" and it looks like this:
sub emitHttpHeader
   print ("Content-type: text/html\n\n");
   print ("<HTML><HEAD><TITLE>WebGeneal $szVersion</TITLE></HEAD>");
   print ("<BODY BACKGROUND=\"$szImageDir$szImageBackground\" LINK=\"#0000ff\" VLINK=\"#800080\" onLoad=\"changeTitle();\">");
   print ($szFont);
You can make changes to the second "print" statement to add <META> tags to the <HEAD>. You can add your own "print" statments between the second and third ones to add your own <SCRIPT>.
TIP: The most common mistake made here is to forget to put a backslash in front of every double-quote character inside the Perl quoted string.
Is it possible to insert a sort of "spy" in the whole database in order to know how many pages (how many pedigree) has been seen, which ones, and by whom?
Yes, it is already in there. Just go into file "" and make certain that setting "$nLogFlag" is set equal to 1 instead of 0. This will cause all subsequent database accesses to be logged. Then create a "log" folder on your web server inside your "cgi-bin" folder and "chmod" the "log" folder to a chmod value of 777. This allows the log files to be written to and stored on your web server. After those steps, you can view the log by running the "" script from your browser, e.g., You have to give your administrative user ID and password. These are defined near the bottom of "".
I am using frames on my web site, and something in the scripts seems to be escaping from the frames. How do I stop this?
Look for every occurrance of TARGET="_top" in files "", "", "", and "" and remove it.
I am using Fill In The Blank Here brand database software. Can I make my database work with your web scripts?
I want the [BREEDING INFO] function to work. What do I have to do?
You need to export a .brw file. If you do not have a .brw file and/or can't export one, you can create one automatically from your .dbw file using the "Make Index Files Utility" program.
Slow search is working, but fast search doesn't return any results. What's wrong?
Slow search and fast search are working, but searching for a Sire or Dam in ("[TRIAL PEDIGREE]") or doesn't return any results. What's wrong?
Can I install the web scripts on my web server and use them to access a database on a different web site?
Absolutely not. Web server security rules forbid this.
Do you have pre-existing databases for Fill In The Blank Here breed that you can give me?
No, I do not provide any databases, other than the fictional/sample small database that comes with the scripts. You must create the database for your breed.
Will your web scripts run on .NET server or use any .NET technologies?
Yes and No. To understand why, let me cover a little terminology (which Microsoft seemingly intends to be confusing).
Before .NET, we commonly used Windows 2000 on our PC's (ignoring the existence of Windows Me, which is different) and Windows 2000 Server on our servers. The Microsoft web server is called "IIS" (Internet Information Server) and their "cgi-like" technology is called "ASP" (Active Server Pages). You would typically use FrontPage to create a script whose filename ends with ".asp".
In this kind of environment, we happen to be running the Geneal scripts on Windows 2000 Server with IIS. BUT, we are using the Perl scripting technology, and IGNORING that ASP even exists (this is why all the script files end with ".pl" instead of ".asp").
NOW that we are using Windows XP on our PC's, the equivalent server operating system is called Windows .NET Server (I do not know why Microsoft decided not to call it Windows XP Server, but they didn't). They still use IIS, but they have enhanced their "cgi-like" scripting technology, and now call it "ASP.NET". A typical .NET cgi script has a file name that ends with ".asmx". To run the pedigree scripts, I am STILL IGNORING the ASP part, and using Perl.
So the ultimate answer is, "Yes, the pedigree scripts will run on Windows .NET Server PROVIDED that the server has Perl installed." The answer is also "No, the scripts do NOT use the .NET technologies (ASP.NET or .NET Common Language Runtime Framework)."
Can we search the database by AKC Registration Number instead of by name?
Yes, if you use Slow Search. It will not work if you use Fast Search.
Can you explain what "chmod" is and why it is important?
If you are familiar with a PC, you might know that the programs on it that you can run are those whose file names end with either ".exe" or ".com". When you double-click on a data file (e.g., ".doc") there are a set of "associations" that determine that all ".doc" files are opened using "word.exe". These are the rules for how to "run things" on Windows.
Web servers also have rules for how to run things. But they are different from the Windows rules, and there are actually two different sets of rules depending upon whether your web server is "Windows NT based" or it is "UNIX based".
If your web server is "Windows NT based" then your ISP usually tells you that you can run scripts by putting them in a certain special directory that has been "turned on" for running things. The web server administrator does this "turning on" by using the IIS Manager, selecting the directory's Properties, and setting the directory's "scripts" property to "Scripts and Executables".
If your web server is "UNIX based" (most web servers in the world are this kind), then the rules for running things depend upon the script files being put into a certain special directory as well as this "chmod" thing. On most UNIX based web servers, the special directory is called "cgi-bin". In more rare circumstances, the directory is called simply "cgi", or perhaps "cgi-xxxxxx" where the "xxxxx" part is replaced with your login id. You can only find out which is correct by asking your ISP or reading instructions on your ISP's web site.
The other part, the "chmod thing" is the UNIX way of doing what Windows calls "associations". In UNIX, a "normal" file (like a data file) has a chmod setting of "644" which means that it is "readable and writable by the owner (you) and only readable by everyone else". A file that can be run ("executable") has a chmod setting of "755" which means that is is "readable, writable, and executable by the owner (you), but only readable and executable by everyone else".
By default, when you use FTP to upload files to your web server, their chmod setting is made to be 644. If you want the file you uploaded to be executable, then you must tell FTP to change the chmod setting to 755. HOW you tell FTP to do this depends upon WHICH version of FTP program you have. The instructions on my web site show how to do it for the Windows default FTP program, as well as for Ipswitch's WS_FTP program.
Can you explain this ASCII vs. BINARY mode stuff? Can't I shortcut past that? How do I know what kinds of files should be transferred BINARY and what kinds need ASCII?
Here's the long explanation.
Windows PC's store "text" files with lines ending in carriage-return and line-feed characters. Unix web servers store "text" files with lines ending in line-feed character only. The reasons for the difference are entirely historical. In order to maintain backward-compatibility, we are stuck with this situation.
The purpose of FTP's ASCII mode is to "strip out" the carriage-returns when you upload a "text" file from a Windows PC to a Unix server (or add them back in when you download).
Microsoft's FrontPage always uses BINARY transfers, i.e., it NEVER does any stripping. It does not know how to do ASCII transfers. Some ISP's have a "File Manager" web page on their web site for uploading files to your own web site. These File Managers also only know how to do BINARY transfers.
Any binary type file (.gif, .jpg, .pdf, .doc, .ppt, .xls, .tif, .tga, .class, and so on) should ALWAYS be transferred in BINARY mode because otherwise they will be corrupted. It is therefore OK to use FrontPage with these files.
Any "browser" destined "text" files (.html, .css) don't really care. The browser ignores any and all carriage-returns and/or line-feed characters in the file, so it doesn't matter whether you have the carriage-returns stripped out or not. You can use FrontPage, or you can use FTP in either ASCII or BINARY mode, no problem.
Any other "text" files (.txt, .pl, .tcl, .cgi, and ALL the pedigree database files .dbw, .brw, .ixw, .bxw, and .kxw) MUST ABSOLUTELY only be transferred using FTP in ASCII mode. Failure to do this will cause the Perl interpreter to go berserk when it tries to read/process the files.
So the "real answer" is that it depends entirely on the file type. Many many people have tried to use FrontPage, or other ISP-provided "binary only transfer" programs to put the pedigree scripts or database/index files on their web site, and caused themselves (and me) no end of troubles.
TIP: This is the single most common mistake made. Please pay notice to this issue.

Changes last made on: Wed 2 Apr 2008 8:55 PM PDT.