Tweet
A little late, but I was on holidays...
*****
Just another big thank you for all the help from every one over the past year.
*****
And a thank you to PowerBASIC. PB6 has been an essential tool for fun in university and has continually outperformed other classmates projects.
Business is going alright with much to do and little time.
And then for the real topic: The TCP relational database server I have been working on will be complete and ready for distribution some time late this year. This database will be freeware and open source for all PowerBASIC programmers. However is will be copyrighted to prevent resale as well as translation to another language... emphasis on the “for PowerBASIC programmers only”. We do intend to market and sell the database outside of the PowerBASIC community.
This database should be an ideal solution for PB programmers working with small to medium sized database needs. If all goes well it should be ideal for large databases as well, however it is still to early in the game to tell for sure.
The major limitation of the current database design will be that in an exchange for an extreme speed increase, it will hold a cache of the entire fixed-width-field section of the database in memory, thus limiting the working database size of the fixed-width-field section to that of your server’s physical RAM. However, there will be a method for archiving unused data. This will of course come with a method for specific access the archived data, but at a slower speed. Feedback?
The database will allow for UDT fields (absolutely anything.) Fixed width data types for speed. Variable width data types for a slower lookup but which may contain such things as entire files of absolutely anything such as music and video! Then there will be field, record, and table pointers types that will enable the use of my favorite part, continually updated queries that may be simply read without compilation at any time. The database server already makes use of multithreading and individual record locking.
It is still up in the air as to the possibility of multiple servers working on the same database in order to allow for a larger client connection base, this might have to wait for version two.
Specific Question to all who are interested: Would providing SQL support be essential, or would a much more programmer friendly (streamlined) communication process be better? At this point I’m thinking both, but don’t want to waist time and code if not necessary.
Any other feedback or suggestions? The more feedback and suggestions I get the more time I’ll put into it. If this is of no interest then I’m happy to keep it proprietary to our needs.
Later on this year I’ll be looking for beta testers as well as those with general expertise that may be interested in optimizing key sections with an experienced hand in assembler.
Colin Schmidt
Praxis Enterprises (just a little consulting and design company with big visions)
Chilliwack (1hour east of Vancouver), British Columbia, Canada
(and yes it is raining here)
[This message has been edited by Colin Schmidt (edited January 10, 2001).]
*****
Just another big thank you for all the help from every one over the past year.
*****
And a thank you to PowerBASIC. PB6 has been an essential tool for fun in university and has continually outperformed other classmates projects.
Business is going alright with much to do and little time.
And then for the real topic: The TCP relational database server I have been working on will be complete and ready for distribution some time late this year. This database will be freeware and open source for all PowerBASIC programmers. However is will be copyrighted to prevent resale as well as translation to another language... emphasis on the “for PowerBASIC programmers only”. We do intend to market and sell the database outside of the PowerBASIC community.
This database should be an ideal solution for PB programmers working with small to medium sized database needs. If all goes well it should be ideal for large databases as well, however it is still to early in the game to tell for sure.
The major limitation of the current database design will be that in an exchange for an extreme speed increase, it will hold a cache of the entire fixed-width-field section of the database in memory, thus limiting the working database size of the fixed-width-field section to that of your server’s physical RAM. However, there will be a method for archiving unused data. This will of course come with a method for specific access the archived data, but at a slower speed. Feedback?
The database will allow for UDT fields (absolutely anything.) Fixed width data types for speed. Variable width data types for a slower lookup but which may contain such things as entire files of absolutely anything such as music and video! Then there will be field, record, and table pointers types that will enable the use of my favorite part, continually updated queries that may be simply read without compilation at any time. The database server already makes use of multithreading and individual record locking.
It is still up in the air as to the possibility of multiple servers working on the same database in order to allow for a larger client connection base, this might have to wait for version two.
Specific Question to all who are interested: Would providing SQL support be essential, or would a much more programmer friendly (streamlined) communication process be better? At this point I’m thinking both, but don’t want to waist time and code if not necessary.
Any other feedback or suggestions? The more feedback and suggestions I get the more time I’ll put into it. If this is of no interest then I’m happy to keep it proprietary to our needs.
Later on this year I’ll be looking for beta testers as well as those with general expertise that may be interested in optimizing key sections with an experienced hand in assembler.
Colin Schmidt
Praxis Enterprises (just a little consulting and design company with big visions)
Chilliwack (1hour east of Vancouver), British Columbia, Canada
(and yes it is raining here)
[This message has been edited by Colin Schmidt (edited January 10, 2001).]
Comment