You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Considering an application written in PBDLL6 that will add, edit, and update records in some sort of a database. The database will not be large, maybe adding about 1,000 records per day. I am trying to figure out whether to just use RANDOM text files and PowerTree for the indexing OR to use an Access database and a third party SQL driver. Any help on pros and cons of each approach would be much appreciated.
If you are adding 1,000 records per day, DO NOT USE ACCESS!
I have seen database after database become corrupted in Access for no reason once the data starts pilling up.
Access is also very prone to crash from any type of network error. In fact just today, one of our new clients who are still using an Access database had there database collapse completely: they could not open it and repair could not fix it. All they had done the last time the database was open is view the data on a networked computer while adding data from the host computer. The database use to have 15,000 members in it.
If you are using your own database files, you can always at least always go in and fix a messed up file manually.
If the client has some money, I highly recommend Sybase. Sybase is much cheaper than something like Oracle and it is also very compact and small: they must have used PowerBASIC
Sybase in the field has proven it's self to compare to Oracle in both speed and stability. What Oracle has that Sybase doesn’t, you won't miss unless you are designing a large international corporate database network.
And that would be my own 2 cents,
Colin Schmidt
------------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada
It depends upon how many indexes to the data you need.
If you can avoid a complex structure, flat files
are the best way to go. Without knowing some sort of
data layout it is hard to say what is the best for you.
I like to preallocate enough records in advance so new
records are updated into the database rather than inserted.
This eliminates file fragmentation and the operating system
from having to continually update the FAT.
With Windows an entire file or portion of it can be loaded
into memory and manipulated very quickly.
I have used SQLTools.dll (PerfectSync software - look for postings from Eric Pearson) at a previous company (I managed to convert them to PowerBASIC from VB - yay!). I found it to be VERY good, and have used it to talk to Access and Oracle with no problems. Have a look at their website...
For a cost of $300, try Artemis. It's very complete and can be used with PB (it's a DLL). It's supposedly faster than Miscrosoft's "Rushmore" technology used in FoxPro and Access.
It sounds like Colin has had some bad experiences with Access. My personal experience is that for small and medium-sized databases in reasonably well controlled environments, Access works just fine. By that I mean that if it is used on a normal "office" sized, typically-reliable network, with well-designed databases, Access might well be the appropriate tool. Keep in mind that Microsoft specifically targets Access at small and medium applications, and SQL Server at medium and large applications. I would not normally consider 1000 new records per day to be large. Maybe not even medium, depending on your perspective and the complexity of the database. 1000 records is only about two per minute for an 8-hour work day. Then again, if adding one record involves updating 8000 inter-related tables, then things can get wild. And if the system will accumulate data for years at a time without archiving it...? There are lots of dimensions to consider.
A major factor in database reliability is database design. I don't mean the platform, like Access vs. Oracle, I am referring to good design practices. If a database is properly "normalized" it greatly reduces the chances of seemingly-random corruption. As does using the most current versions of ODBC drivers, etc. (I'm not implying that Colin's database isn't well designed... he might have a flaky network to deal with, or unusual load "peaks", or some other factor. Lots of things can go wrong with computer hardware/software systems!)
And of course, regular backups and/or data replication are always recommended, so that when failures do occur, the damage is minimized. I once read that if cars had evolved as rapidly as computers we'd all be driving Jaguars that went 500 miles an hour, got 1000 miles per gallon, cost $50... and self-destructed once a year, killing all of the occupants.
All that being said, I'm not sure that Access is right for Phil. (I just didn't want people to be scared away from Access, with which I've had good results.) Phil's choice of flat-file vs. SQL database vs. whatever should be based on what he will need to do with the data.
SQL is not right for every job. If your project is a design-it-once, single-table database, and you don't need any kind of "query" capability to retrieve the data in different and flexible ways, then a self-designed flat file might be best. I use them all the time!
But when I have a project where I don't want to have to write an ad-hoc Report Generator for the data, for example, SQL makes sense because I can use Access, Crystal Reports, or any of several other off-the-shelf products to cut my development time way down.
Using a standard SQL database allows me to use other applications with my data, and to use my data with other applications. I can "export" it to Excel, or to a flat file, or to virtually any other standard format with very little effort.
Using a standard SQL database also gives me an easy way to modify the datbase in the future, without having to re-code everything and write file convertors. I can add a column to a table -- or add a whole new table -- and old versions of my programs will still work perfectly. Newer versions can take advantage of the new "features" of the database, but customers are not required to upgrade.
Remember, a package like Access (or any of several other fine database systems) usually contains a GUI-based database design system, a report generator, an ad-hoc query tool, a GUI "form designer" that allows you to present the database to your users for display and updating in dozens or hundreds of different ways, a security system that limits access to certain data, a database "repair" utility, and many other tools. If you have time to write all of those things, great! But an off-the-shelf SQL-based package delivers a tremendous bang for a very few dollars, compared to the hours that would be required to re-invent it. Best of all (in my admittedly-biased opinion), PowerBASIC programs can access SQL databases too!
If you don't need any of those things, that's great too! Create a very efficient, highly specialized proprietary file format, and your app will probably run better and faster than any SQL-based database. There is no reason to add the overhead of SQL if you don't need what it provides.
I don't know if you know wath MSDE is (the link posted by Siamack Yousofi). MSDE (Microsoft Data Echange)work with the same file as the SQL server, but it is a light SQL engine (with all the fonctionalities) but can manage just files of 2gb. It is free...
But to be able to work with it, you must have Visual Sutdio (cluff licence) or Office 2000 prenium and up.
It is the futur replacement of Acces Jet engine.
---------------------------------------------------------------
Francis Beaulieu
FrabLaser Softwares
------------------
Francis Beaulieu
Prog senior of 17 years.
Microsoft Specialist
I do, but the original poster specifically said that his app was written in PB/DLL 6.0, and MSDE apps can only be written with Visual Studio. Unless I'm mistaken, MSDE does not provide an ODBC interface, so non-Microsoft apps can't use it to access a database, much less use it for development. After all, MSDE stands for Microsoft Data Engine, and it is apparently intended for Microsoft-language apps only.
> It is the futur replacement of Acces Jet engine.
Has Microsoft actually said that? The current Jet Engine supports SQL Server, Access, Excel, dBase, FoxPro, Paradox, and others, and as I understand it MSDE supports SQL Server only. I believe Microsoft is only saying that MSDE is "An Alternative to Jet for Building Desktop and Shared solutions".
By the way, in addition to the hardware limitations you mentioned, I've heard that MSDE is not 100% happy on 95 and 98 machines.
In any case, Microsoft is still standing firmly behind ODBC, which is the "universal" access method for SQL databases (and the method that SQL Tools uses). See the Microsoft White Paper at http://www.microsoft.com/Data/ODBC/wpapers/odbcnole.htm for more information.
Call me too conservative, or call me too cynical, but I always hestitate to adopt Microsoft's "Next Big Thing" as soon as it is released. If MSDE appears in two consective versions of Visual Studio, then I'll take it more seriously.
Bob,
If you have any good or bad experiences with
Artemis, please let me know. I bought it, but
haven't used it much. It is dBase compatible
in case others don't know what it is.
you need have the version 3.7.0623 or higher of SQL server ODBC driver... Because MS give the same DLL name to different driver versions, you have to go in the ODBC manager to see if you got the proper driver. If not you can download the last MDAC package.
Then I think that you will be happy about those news... But SQL server is around 2K$ and Visual Studio 1K$, you must need it very well...
---------------------------------------------------------------
Francis Beaulieu
FrabLaser Softwares
------------------
Francis Beaulieu
Prog senior of 17 years.
Microsoft Specialist
Don't think to pass to MSDE too fast, because it can only share ~5 to 10 concurrent (more 5) users at a time, Access jet can handle from 0 to 255 users at a time (the reality will be more 10-20)...
That's a huge difference between SQL server who can handling more than a few thousand (to depending of the hardware)...
Then, MSDE is an other measure of Microsoft to sell a very expensive SQL server (less expensive than Oracle !)...
MSDE is just for give to you the taste of true client/server SQL... Or to be used as a portable solution for synchronized databases who have to move with laptops(and salesmen as well)...
------------------
-------------------------------------------
Francis Beaulieu
FrabLaser Softwares
Francis Beaulieu
Prog senior of 17 years.
Microsoft Specialist
Please note: VB stands for Variable Block not Visual Basic!
VB/ISAM is 25 times faster than access!
VB/ISAM is only 70K bytes!
VB/ISAM stores variable length data!
VB/ISAM runs on any network!
VB/ISAM supports multi user access & full record locking!
In fact, (sorry dave) it blows PTree out the door!
Thanks for the information Michael, I'll have to see what we can find out about verifying your claims.
To date, thousands of PowerTree users have let us know that they haven't found anything faster or easier to use. That's not to say that such a product doesn't exist, only that neither we, nor our existing user base have managed to find anything better.
I visited the link you provided. It doesn't look like VB/ISAM includes support for PowerBASIC, which means that PowerBASIC users will need to port the declarations and example code over themselves. From VB, it's probably not too big of a deal.
Also, from what I can tell, it's not nearly as flexible as PowerTree since it uses its own proprietary data format... Can't use it with existing databases. And at $269, it's more than twice the cost of PowerTree.
I don't doubt that it's a good product, but definitely not for me.
You're right Dave.....the price is high, but I had several problems with PTree, (emailed many times last year for answers)...(got several reply's that someone would get back to me)...but never no answers, so I needed another db engine to get things in motion for a clients db. Several hundred thousand records for a shipping company. Without PB, though, it would have been very slow with M$-VB.
You're also right, had to restructure some of the include files, but it was worth the time. The code structure is more difficult than PTree, but VB/ISAM does everything on the fly. Porting db's was not too bad. The more important thing was it allowed me to get the work I needed at that time! My Client paid for the program as well as yours!
I hope that sometime in the future, PTree is looked at and maybe a 2nd version will come out in the future.
[QUOTE]Originally posted by Michael Meeks:
I use: VB/ISAM 5032 - http://users.ntr.net/~software_src
VB/ISAM is 25 times faster than access!
Michael,
What gyrations did you have to do to utilize VB-style dynamic
strings? with vb/ISAM?
Are you still happy with it?
I own PowerTree and like it for a lot of things, but I need
variable-length records and I don't want to figure out (or debug)
the garbage-collection involved.
Thanks
Brad Olson
brado(Take Out This Anti-Spam Parenthetical Clause)@att.net
You guys must have received a better evaluation
than I did. I received an old system that had
no documentation, no pricing was dated 2 years
old and didn't work. I've called the company
and got an answering machine (408-224-8778).
Is this company still in business?
Many of their web pages are years old.
Did find one comment made in May.
Also, email is relay denied at [email protected]
[This message has been edited by Mike Doty (edited November 22, 2000).]
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
Comment