Hey..
Just a note to let you know I'm testing GALSQL.DLL - a library that enables embedded SQLite databases instead of / in concert with BTrieve databases within Worldgroup 3.x. In order to test it, I converted ThinkDice! to use it. So far, so good...
I picked SQLite because it's fast, small, and built to be an embedded SQL database engine. In order to make it work, however, I had to switch from Borland C++ 5.02 to Borland C++ 5.5.1 - the good news is that it works, and I can compile other modules and libraries using that to no ill effect.
I'm going to try something else with it now.. probably one of the 'core' modules.
Embedded SQLite Module
Moderator: Mod Squad
I thought I read a post somewhere on here about someone who did replace Btrieve with the Pervasive 9.5 SQL Package. Here it is I believe.
My bad, I read through the post again and I guess this is just an Updated Betrieve or something.
http://www.themajorbbs.com/bbs/viewtopi ... hlight=sql
My bad, I read through the post again and I guess this is just an Updated Betrieve or something.
http://www.themajorbbs.com/bbs/viewtopi ... hlight=sql
Pervasive is the company that bought Btrieve and that was the SQL version, you can convert to that and it does work but in the testing that I have done I have found it unstable with some add-ons but it did work on simple configurations, there is a few systems using it with MajorMUD to get information to the web so again it does work.
I think what Questman is looking for is something more stable and a lot faster and SQLite is a great option to do just that.
I think what Questman is looking for is something more stable and a lot faster and SQLite is a great option to do just that.
-
Stoneslinger76
- Posts: 427
- Joined: Wed Apr 23, 2008 12:01 pm
- Location: Kitchener, ON, Canada
- Contact:
Re: Embedded SQLite Module
Best news Ive heard in a long timeQuestman wrote:Hey..
Just a note to let you know I'm testing GALSQL.DLL - a library that enables embedded SQLite databases instead of / in concert with BTrieve databases within Worldgroup 3.x. In order to test it, I converted ThinkDice! to use it. So far, so good...
I'm going to try something else with it now.. probably one of the 'core' modules.
looking forward to the core modules!Stoneslinger
telnet://theswampbbs.net or http://theswampbbs.net
telnet://theswampbbs.net or http://theswampbbs.net
Pervasive SQL is a great product. Pervasive bought BTrieve, and their later products are somewhat backward compatible with the old BTrieve record manager -- the BTrieve in Worldgroup 3.2 IS supported.
However, it's not an optimal solution for a few reasons:
- When upgrading components, I would like to use industry-standard off the shelf solutions rather than proprietary solutions. This increases the number of people (exponentially) who are familiar with a particular solution, hence, providing a greater pool of resources for me and the community to work with the solution, and for a greatly reduced cost.
- I also would prefer to use open source or free software solutions where possible. SQLite is public domain software, so it doesn't get any more open than that. Pervasive is commercial and would require a new distribution license to use.
- SQLite is an ANSI SQL compliant database - this is key because the SQL (structured query language) is easy to learn, use, and is the most popular way to interface with databases.
Yes, the goal here would be to completely replace BTrieve if possible. ThinkDice works great using SQLite for its top ten and scores database and seems to have no ill effects on the system as a whole. Of course, it's a small example and I'd like to try something bigger. I'm also not sure my implementation is optimal so I'll try a few different things. BTrieve (DFAAPI) in WG had a lot of structure around it where the Developer didn't have to do much -- define the record size, then you pass a pointer to the struct to almost all the functions, and a pointer to the BTrieve database file to all of them. This was simple but lent itself to a lot of memory management in C that is dodgy -- the cause of most application instability on the NT platform for WG. On the flip side, using GALSQL will require more coding on the developer's side to define prepared statements, queries, process resultsets, etc, but this has benefits:
- it uses a standard SQLite interface. The code used is DIRECTLY PORTABLE between WG and Non-WG software using SQLite
- it has no behind the scenes memory/pointer handling
- the developer decides how to interface with databases
GALSQL.DLL doesn't do ANYTHING but implement the SQLite database in a linkable DLL. It's literally 100% SQLite 3.6.1 code.
However, it's not an optimal solution for a few reasons:
- When upgrading components, I would like to use industry-standard off the shelf solutions rather than proprietary solutions. This increases the number of people (exponentially) who are familiar with a particular solution, hence, providing a greater pool of resources for me and the community to work with the solution, and for a greatly reduced cost.
- I also would prefer to use open source or free software solutions where possible. SQLite is public domain software, so it doesn't get any more open than that. Pervasive is commercial and would require a new distribution license to use.
- SQLite is an ANSI SQL compliant database - this is key because the SQL (structured query language) is easy to learn, use, and is the most popular way to interface with databases.
Yes, the goal here would be to completely replace BTrieve if possible. ThinkDice works great using SQLite for its top ten and scores database and seems to have no ill effects on the system as a whole. Of course, it's a small example and I'd like to try something bigger. I'm also not sure my implementation is optimal so I'll try a few different things. BTrieve (DFAAPI) in WG had a lot of structure around it where the Developer didn't have to do much -- define the record size, then you pass a pointer to the struct to almost all the functions, and a pointer to the BTrieve database file to all of them. This was simple but lent itself to a lot of memory management in C that is dodgy -- the cause of most application instability on the NT platform for WG. On the flip side, using GALSQL will require more coding on the developer's side to define prepared statements, queries, process resultsets, etc, but this has benefits:
- it uses a standard SQLite interface. The code used is DIRECTLY PORTABLE between WG and Non-WG software using SQLite
- it has no behind the scenes memory/pointer handling
- the developer decides how to interface with databases
GALSQL.DLL doesn't do ANYTHING but implement the SQLite database in a linkable DLL. It's literally 100% SQLite 3.6.1 code.
Acti-BASE is ok but the powerlink package is much nicer, i did some small workups using the powerlink SDK which utilizes SQL and so far so good i havent totally strayed away from btrieve but was considering slowly bringing it in with newer releases of Tele-Arena next year, and maybe version 3.00 of arctic-trivia will be 100% SQL.Syclops wrote:Didn't ActiBase do something with SQL Databses or is this used for something different?
you can update to pervasive but from a developer standpoint it is still pricey, if i released a module using pervasive i would have to pay per copy, NetVillage considered doing wg 3.30 using pervasive and it was really pricey.Syclops wrote:I thought I read a post somewhere on here about someone who did replace Btrieve with the Pervasive 9.5 SQL Package. Here it is I believe.
My bad, I read through the post again and I guess this is just an Updated Betrieve or something.
http://www.themajorbbs.com/bbs/viewtopi ... hlight=sql
The problem with Actibase and Powerbase is that they're ODBC type solutions that are basically layers in between your code and the database rather than a direct driver type approach. They're not as efficient. Plus, of course, you're at the mercy of the ISV developers, which in this business, is risky.
agreed, thats why i have played with it and havent really depended anything upon it, i wrote my own active-html output from my databases so i have actually been doing pretty well without it but am interested to see how this GALSQL turns out.Questman wrote:The problem with Actibase and Powerbase is that they're ODBC type solutions that are basically layers in between your code and the database rather than a direct driver type approach. They're not as efficient. Plus, of course, you're at the mercy of the ISV developers, which in this business, is risky.
i been hoping something like this would come out so a forum replacement could be written to be like phpbb, etc.....
I was one of the few people that tried pervasive sql with mods other than MajorMud. Generally, most of the stuff seemed to work well, but I did have a problem with running one mod: the rose - council of guardians. I re-installed it a few times from scratch to make sure there were no messed up files or any thing, and it never worked. That was the only problem I had running it.
There are several reasons I didn't stick with pervasive sql.
First, there was no speed or performance increase.
Secondly, why pay money for something that doesn't increase performance?
It's a long setup process, to say upgrade from one pc to the next, or to do it on the fly when a hard drive crashes or server burns up... It's not as simple as just copying your setup from a cd or dvd on to the hard drive.
The benefits of running an sql system far outweight the cons, but there is a catch: you have to know php, probably some other programming, and be an expert in databases. If I could have done half of what they've done with the majormud control panel project, for all of my worldgroup games, I would have definitely stuck with pervasive sql.
If there was a simpler way to do this, I would probably go for it.
Correct me if I'm wrong, but here are some things I think could be possible if worldgroup went to sql:
All databases are edible on-line, with out shutting the server down (we this in the major mud control panel, correct?)
If all database information is viewable, configurable, edible online, then that means those games could also be playable on the web, possibly by creating a web engine for the interface. If you can edit all databases with out knowing their source code, then that means you can take just about any game and give it a web makeover, right? BBS players could then interact with web players.
Use one sign-up process to authenticate several services... I believe I've seen some synchronet bbs systems with php use this type of authentication for black nova traders and legend of the green dragon web games. If synchronet can do it, worldgroup must be able to do it somehow too.
If we can authenticate other services, we could also authenticate other worldgroup systems, therefore bypassing the need for dma servers. Of course, it probably wouldn't work for DOS though, unless some one can figure out a way to make a major bbs dos=windows interpreter of some kind.
If all of this could happen, it would allow us to run our own message boards - just about anything is better than worldgroup's forums. It would basically allow us to run our own complete, updated online service, as opposed to just a BBS with a web server.
There are several reasons I didn't stick with pervasive sql.
First, there was no speed or performance increase.
Secondly, why pay money for something that doesn't increase performance?
It's a long setup process, to say upgrade from one pc to the next, or to do it on the fly when a hard drive crashes or server burns up... It's not as simple as just copying your setup from a cd or dvd on to the hard drive.
The benefits of running an sql system far outweight the cons, but there is a catch: you have to know php, probably some other programming, and be an expert in databases. If I could have done half of what they've done with the majormud control panel project, for all of my worldgroup games, I would have definitely stuck with pervasive sql.
If there was a simpler way to do this, I would probably go for it.
Correct me if I'm wrong, but here are some things I think could be possible if worldgroup went to sql:
All databases are edible on-line, with out shutting the server down (we this in the major mud control panel, correct?)
If all database information is viewable, configurable, edible online, then that means those games could also be playable on the web, possibly by creating a web engine for the interface. If you can edit all databases with out knowing their source code, then that means you can take just about any game and give it a web makeover, right? BBS players could then interact with web players.
Use one sign-up process to authenticate several services... I believe I've seen some synchronet bbs systems with php use this type of authentication for black nova traders and legend of the green dragon web games. If synchronet can do it, worldgroup must be able to do it somehow too.
If we can authenticate other services, we could also authenticate other worldgroup systems, therefore bypassing the need for dma servers. Of course, it probably wouldn't work for DOS though, unless some one can figure out a way to make a major bbs dos=windows interpreter of some kind.
If all of this could happen, it would allow us to run our own message boards - just about anything is better than worldgroup's forums. It would basically allow us to run our own complete, updated online service, as opposed to just a BBS with a web server.
No, it isn't that simple just to take the databases and make them accessible. SQLite would indeed allow you to edit the data online while the system's running from external sources, as well as read them and report on them. It'd be just like any SQL engine, such as MySQL. The advantage is that SQLite is developed as an embedded engine which is essential for performance.
But a game with a web makeover? What about all of the product logic? That's the core of any software product, not the data. The data is important, but it's secondary. There are things you could do, though - you could create a lot of supplemental products. For a game like a MUD game, you could:
- Have a web Flash-based real-time interactive map - see who is where, the state of the game, etc. Sort of like the Maurader's Map in Harry Potter.
- Have realtime scoreboards
- Have statistics, character profiles, etc.
I mean, you could do this with Btrieve too, if you knew the structures. But it's exponentially simpler with standard SQL.
But a game with a web makeover? What about all of the product logic? That's the core of any software product, not the data. The data is important, but it's secondary. There are things you could do, though - you could create a lot of supplemental products. For a game like a MUD game, you could:
- Have a web Flash-based real-time interactive map - see who is where, the state of the game, etc. Sort of like the Maurader's Map in Harry Potter.
- Have realtime scoreboards
- Have statistics, character profiles, etc.
I mean, you could do this with Btrieve too, if you knew the structures. But it's exponentially simpler with standard SQL.
Yeah, I see what you're saying... I still believe an engine could be made to run to modify data, but what I really didn't think about is that it would be be running two different engines/games, just sharing data. And as far as not needing the source code, you probably would need to know every bit of the inner workings of any game to know how to deal with statistics.
How hard could it be to take a simple, non-interactive game like card sharks or chain reaction and have them work on the same database? (one on worldgroup, obviously, one for the sql server) - if some one could get something like that to work, they could start with more interactive games.
Card games would actually be a good choice for web games, considering you don't have fast action X/Y cordinates to keep track of with any bbs games, and it would be easy to make some cards and have vga graphics.
With muds or adventure games, which I'm sure would be a lot harder, you could have some 3-d graphics, kind of like the old wizardry and swords and serpents type games.
Here's an idea of what I'm talking about, except this is ansi graphics:
This is Adventure's Maze II. I don't expect anything to come out of BBS modules to suddenly become world of warcraft lol..
How hard could it be to take a simple, non-interactive game like card sharks or chain reaction and have them work on the same database? (one on worldgroup, obviously, one for the sql server) - if some one could get something like that to work, they could start with more interactive games.
Card games would actually be a good choice for web games, considering you don't have fast action X/Y cordinates to keep track of with any bbs games, and it would be easy to make some cards and have vga graphics.
With muds or adventure games, which I'm sure would be a lot harder, you could have some 3-d graphics, kind of like the old wizardry and swords and serpents type games.
Here's an idea of what I'm talking about, except this is ansi graphics:
This is Adventure's Maze II. I don't expect anything to come out of BBS modules to suddenly become world of warcraft lol..
thats what we need edible databases.Malakai wrote:I was one of the few people that tried pervasive sql with mods other than MajorMud. Generally, most of the stuff seemed to work well, but I did have a problem with running one mod: the rose - council of guardians. I re-installed it a few times from scratch to make sure there were no messed up files or any thing, and it never worked. That was the only problem I had running it.
There are several reasons I didn't stick with pervasive sql.
First, there was no speed or performance increase.
Secondly, why pay money for something that doesn't increase performance?
It's a long setup process, to say upgrade from one pc to the next, or to do it on the fly when a hard drive crashes or server burns up... It's not as simple as just copying your setup from a cd or dvd on to the hard drive.
The benefits of running an sql system far outweight the cons, but there is a catch: you have to know php, probably some other programming, and be an expert in databases. If I could have done half of what they've done with the majormud control panel project, for all of my worldgroup games, I would have definitely stuck with pervasive sql.
If there was a simpler way to do this, I would probably go for it.
Correct me if I'm wrong, but here are some things I think could be possible if worldgroup went to sql:
All databases are edible on-line, with out shutting the server down (we this in the major mud control panel, correct?)
If all database information is viewable, configurable, edible online, then that means those games could also be playable on the web, possibly by creating a web engine for the interface. If you can edit all databases with out knowing their source code, then that means you can take just about any game and give it a web makeover, right? BBS players could then interact with web players.
Use one sign-up process to authenticate several services... I believe I've seen some synchronet bbs systems with php use this type of authentication for black nova traders and legend of the green dragon web games. If synchronet can do it, worldgroup must be able to do it somehow too.
If we can authenticate other services, we could also authenticate other worldgroup systems, therefore bypassing the need for dma servers. Of course, it probably wouldn't work for DOS though, unless some one can figure out a way to make a major bbs dos=windows interpreter of some kind.
If all of this could happen, it would allow us to run our own message boards - just about anything is better than worldgroup's forums. It would basically allow us to run our own complete, updated online service, as opposed to just a BBS with a web server.
no more cold pizza and warm soda for us sysops...
Sure. I still want to battle test it. When I get more time I want to hook it into the mainline stuff for a bit and see how that works.Talonp wrote:Hey Questman just wanting to know the status of the GALSQL.DLL? Been out of the loop for a month or two due to a illness ... but I am slowly getting back to working on the BBS stuff
Let us know the status when you can ...Thanks!
It appears to work...
hey i did a mud engine last night using powerlink and ODBC send me the GALSQL and any docs and ill battle test it for ya.Questman wrote:Sure. I still want to battle test it. When I get more time I want to hook it into the mainline stuff for a bit and see how that works.Talonp wrote:Hey Questman just wanting to know the status of the GALSQL.DLL? Been out of the loop for a month or two due to a illness ... but I am slowly getting back to working on the BBS stuff
Let us know the status when you can ...Thanks!
It appears to work...
ill whip a small game engine like i did with PL or maybe a small trivia module which is all database dependent.
the next major release of Tele-Arena is gonna use something other than Btrieve so would be nice to check this option out.