Hi all,
I'm kind of familial with DBMan, the free version. I'm thinking of buying the SQL version, because I think I will need it in the near future.
Only I like to know before I start:
Where do I have to think of, when I will implant SQL into my fine working version. Does the whole script (structure) have to be changed and does it work with the same variables and modifications and so on.

You will need to re-write most of the modifications. including What's New, Send Mail, Password Secure Lookup, etc. into SQL rather than straight Perl. It will work with this modifications, however, as mentioned, you will have to re-write them to work with the SQL Version.

For more information, check out some of the discussions in the LINKS SQL Forum...while not directly related to DBMAN...the logic behind upgrading is the same.

Regards,

------------------
Eliot Lee
Anthro TECH,L.L.C
www.anthrotech.com
* Be sure to visit the Resource Center for FAQ's, Modifications and Extra Goodies!!
* Search Forums!
* Say NO to Duplicate Threads. :)
----------------------

I have tried the flatfile version of DBMan and want to buy the DBMan SQL version.

1. I wanted to know if the SQL version supports:

- Multiple Keyword Search with relational operators. Does it have functionality to AND & OR Keywords
- Does it have Long & Short MOD incorported or one has to do the MOD
- Are there any restrictions on record size and table sizes in this version or mySQL.
- Are there any restriction on the number of tables, in case I want to set up a slightly more complicated structure at a later date.

2. Does setting up the SQL version mainly involves modifying the .cfg file. And if customization of html.pl is possible to change the look like in the flatfile version. What else is required to make it work if it is more complicated that this.

Lastly, point me to some good sites that are already using the DBMan SQL so that I can see the version in action. I'm also interested in knowing how big are these databases in terms of MB/GB.

Would really appreciate any help. Thanks.

HB

Eliot and I have discussed this recently in another thread. Any mod which access the .db file directly will have to be altered to work with the SQL version. The html coding is the same, however.

Mart, if you look over your html.pl file, any time you see an "open" statement, that will have to be changed. And I can't help you with the change because I don't know SQL.

HB (or is it TIF?), in answer to your questions:

The search capabilities in the SQL version are the same as in the non-SQL version. The functionality is the same.

There is not a short/long mod built in to the SQL version, but the one on my site will work with SQL.

As far as I know, there is no restriction to file size, table size or number of tables in the SQL version.

Setting up the SQL version involves setting up the .cfg file, which is similar (although not identical) to the non-SQL version. There is an installer script which actually creates the tables on your server, which you must run before you start using the database. And the db.cgi file is very different in that it uses SQL to access the tables instead of opening, reading and closing text files.

The html.pl file, as it comes in the distribution and before you make any modifications, is identical to the non-SQL html.pl file. You can use any modification that does not involve opening and closing files in the SQL version. If you see the word "open" in a mod, know that the mod will have to be adapted before it can be used with the SQL version.

I don't know of any sites that use the SQL version of DBMan.

------------------
JPD

Visit the following web site to see a working example of DBMAN SQL in action....

http://www.ifcae.org/...=bib&uid=default

I helped with the development of the database in regular DBMAN and Alex assisted the site owner with upgrading the database to SQL.

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.

To see dbsql in action, you might also want to look at http://www.woelfelbuch.de. The database has 7000+ records and it is quite fast (even if the server is slow sometimes).

Alex helped with the mod to perform a "additions of the last x days" search (Neueingänge). The rest was quite straightforward.

Hope this helps.

Heiner

I've been really considering putting forth some effort in converting my database over to SQL using the Perl DBI/DBD modules. I'm not all that savy with either yet, although it sounds like the right direction to go with this based on what I've been reading about.

I'm assuming that one of the benefits of moving to the SQL is having the relational database already done. I'm wondering if this is going to effect the relational database mod I've already implemented in my program? Or can I just continue using it? Both my html.pl files are already customized fairly heavily, and I'm not sure how easy it would be to integrate all into one file- same goes for both of the .cfg files.

From what I gather it sounds like the DB.CGI file is where most of the changes will need to be made, and probably some to AUTH.PL as well.

This brings about another question. Would it simplify things at all to just convert over anything read/written to the .db files? and leaving the .pass file as plain text? It seems to me the the .pass file isn't accessed or changed that often when the database is being used. I also like being able to manually edit the file, if I need to quickly change a permission setting, email address, etc. So maybe it isn't worth spending the time to convert that too, or is that really no more difficult than converting the .db files? any thoughts on that?

I've been reading in this thread about what SQL statements will replace. Is there more to just replacing the open/print FH statements, or is that really all there is to it?

Also, if anyone is interested in learning SQL, I found a pretty descent tutorial on the web. I've been reading over it the past couple of days, and have learned quite a bit from it already.

http://w3.one.net/~jhoffman/sqltut.htm

Here's a link to the Perl DBI homepage, which is most definately worth reading:

http://www.symbolstone.org/technology/perl/DBI/index.html

Frank

A question along these lines: If a MOD works independant of other subs (such as the counter MOD) and uses standard PERL file access commands, will it work as-is in the SQL version, or will it have to be revamped to an SQL-type MOD?

--Lee

 
No...the Mods will have to be re-written to use SQL access commands to access and pull data from the MySQL table (or other SQL-type of tables).

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
Anthro TECH, L.L.C
anthrotech.com
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.

You can probably use it as-is. It's just that any access to the .pass file or .db file will have to be revamped.

Fortunately, you can still use calls to subroutines like get_record. The subroutine names are the same.


------------------
JPD

Another site to check out is http://www.vettracker.com. We are using the sql version and the regular version. There are over 23,000 records in the vets section alone.

Does anyone know how much DBMan SQL can take? I know that DBMan can only take about 1MB total...and I know that the SQL version can take more...but I havn't been able to find out how much more...anyone know?

Chris

According to mysql.com, it's rated for 50,000,000+ records hehe

Well that still doesn't quite get at what I'm looking for...50,000,000 records might be possible if each record is small...is there a certain size it can handle? 10MB? 100MB?

Chris

Check out www.mysql.com...you may find better answers there. Also, check with your hosting company to see how large the MySQL tables can become. Many hosting companies put a cap on data contained in the tables.

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
Anthro TECH, L.L.C
anthrotech.com
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.