sanbachs.NET Serving the DataPerfect* Community

Firestorm – Frequently Asked Questions

Earlier questions remain available.

Thanks to Jeroen Vader for questions 10 through 14. And to Larry Neuton for question 15. Thanks to Pieter Vankeerberghen for question 16.

Question 10. I understand there's a need to generate the panel byte array description for an STR, and that the resulting pba.c is then used to generate a separate executable for every database. How difficult would it be, in your opinion, to write a general executable instead, and then have the database definition (the STR) read after running this general executable? This would be more like the situation of running DP.EXE and then loading an STR on demand. Do you have any idea on how this would affect speed and/or memory usage? Would it be possible by writing something on top of dpif.c? (My C knowledge is not so thorough to immediately judge this, unfortunately.) The rationale behind my question is that one general executable would make development easier.

Answer 10. This could be done, and should have very little effect on memory usage. Each script would take a little bit more time to run because each one would have to read the STR file before it began. By generating the pba.c offline, this work is done only once.

Question 11. Am I correct in understanding that you need to recompile

• after having performed an index regeneration (root index position changes)
• after adding/changing/removing a field definition (field definition changes)

Answer 11. The pba.c file will need to be regenerated and recompiled whenever there is a change to real fields or index definitions.

The question of root index positions is more delicate. The METADXP program does not export the root index position information from the STR file. Instead there is a report in METAD that assigns index base blocks in a standard way. After changing an index definition, you will need to delete the .IND file and have DataPerfect recreate the index file and then recreate the indexes for all panels.

Question 12. Is there any other reason apart from lack of time and/or effort that it's been decided not to add userID checking yet?

Answer 12. This needs to be added in each CGI script where it is needed. We have developed a few techniques for doing this and will document them soon.

Question 13. Is the FORTH code in dot.c a subset of the code used to generate DP.EXE?

Answer 13. No, it was developed independently, by the same author.

Question 14. In the case of G- and H-fields with decimals the procedure does not produce correct results when the decimal point is NOT '.'. On the European continent, we generally use '.' as thousands separator, and ',' as the decimal 'point'. When following the pba.c generation procedure as it currently is, a 'GZ.ZZ9,99', would contain 6 decimals, while we Europeans would expect 2. This information is correctly stored in the STR, but not read by the metadxp.com program. Panel 1 of the metad database has the '.' hardcoded in the field formula for P3F28. This then creates errors in the generated pba.c files.

Answer 14. You are correct. The METAD database will need some changes to handle this. Also, the function FSformatG will need to be improved.

Question 15. Is there a simpler way to display data from just one panel to the web? It would be great if a user of my library automation program could display a library catalog (i.e., the data from the "Library Catalog" panel) on the web. I took a brief look at the Firestorm site but it seems technically over my head... I don't know anything about C or Perl programming and only a rough idea of how cgi scripts work.

Answer 15. sanbachs.NET offers a hosting service that may be of interest.

Question 16. We share a rather large DP application with passwords (3 levels - one to change structure and two to read/write). We would like to write and read in this DP using Firestorm, but how do we have to deal with these passwords?

Answer 16. Firestorm coordinates data access, using the index and data files together in a manner that is compatible with DataPerfect. However, it does nothing special with passwords, keep-a-total, formulas, etc.

Furthermore, on the web there is no notion of session. With DataPerfect, each user is running the DP client software on their own workstations. Browsers do not maintain any information about what the user is doing, or who they are, from one web page request to another.

Here is how I have dealt with passwords.

A DP application with passwords will usually have a USER_ID panel. For example, this might be panel 43. To this panel, add two fields, one for an IP address and one for a timestamp. For example, these might be fields 4 and 5 of the USER_ID panel. Also, add a new index using field 1 and the IP address. Then, in each CGI script, call a function like the following:

 1 int authenticate(Field_Value *ID, Field_Value *IP)
 2 {
 3   FS_panel p43;
 4   char AuthTime[15];
 5   time_t authTime, now;
 6   Field_Value *nowTime;
 7
 8   p43 = FSsetPanel(43);
 9   if ((FSequalRec(p43,FSifList(p43,2,ID,IP))) != FS_OK) {
10     return 0;
11   } else {
12     authTime = atol(FSfield(p43,5)->field_data);
13     time(&now);
14     if ((now-authTime) <= 1800) { /* one half hour of inactivity */
15       sprintf(AuthTime,"%ld",now);
16       nowTime = NewField('3',5,strlen(AuthTime),AuthTime);
17       FSupdateField(p43, FSifList(p43,2,ID,IP), 5, ':', nowTime);
18       return 1;
19     }
20     return 0;
21   }
23 }

Pass the user id from web page to web page. This can be done either using hidden fields in each form, or by a technique called "URL stuffing" which includes it in each URL. In each CGI script, call the function defined in line 1 early and if it fails (returns zero) invite the user to login again. Authentication can fail for two reasons. In line 10 it fails because there is no record for the user and IP address. In line 20 it fails because the user has been inactive for over 1800 seconds. In line 17 the function updates the record to the current time.

To start the authentication process, use code like the following right after the user has logged in:

 1 time(&now);
 2 sprintf(AuthTime,"%ld",now);
 3 nowTime = NewField('3',5,strlen(AuthTime),AuthTime);
 4 FSupdateField(p43, FSifList(p43,1,ID), 4, ':', IP);
 5 FSupdateField(p43, FSifList(p43,1,ID), 5, ':', nowTime);

This gets the current time as a long integer (line 1), converts it to a character string (line 2), creates a new field value from this string (line 3), stores the IP address in the USER_ID panel (line 4), and stores the current time in the USER_ID panel (line 5).

Contacting sanbachs.NET

Sign or browse our guest book.

Disclaimer