Am using CodeGear 2007 Win32 with dBase, ACE Reporter, Woll2Woll, JEDI components; therefore I have a lot of TTables and TQueries throughout my program. My applciation runs on a 2003 server with XP workstations. The response time to access data (retrieve, post, do SQLs) is horrible. The users are demanding something better. But I don't know what is better. And I don't know what the ramfications are in changing to something better.
I sincerely hope that someone can give me recommendations as well as address the difficulty in changing to another database.
I'm glad you asked. BDE replacement databases are something I've been following for years. My Delphi coding life changed for the better dramatically when I discovered DBISAM. I wrote an article about it for the now defunct "Delphi Informant" magazine in which I commented that "DBIISAM behaves more like the BDE than the BDE."
Prestwood has used DBISAM for a couple very ambitious client projects and we've never had a single defect reported that could be traced to the database. It just flat works.
Performance is very, very good; but you have to do your part in designing and coding well.
It is very easy to migrate from dBASE to DBISAM; the product includes a BDE migration utility.
You're project's design will dictate how much work it will take to actually complete the switch to DBISAM. If you used a TDataModule descendant. and kept any sort of TDataSet off your forms, it can be quite easy. If you did it the "old way," and put TTables and TQueries directly on your forms, life will be a little harder - but still not bad.
Note: Unlike dBASE or Paradox, DBISAM can be used as a local, single-user database; a shared-file, multi-user database; or as a real client/server solution.
You should also know that the makers of DBISAM, Elevate Software, have a newer database called ElevateDB. This product is a lot more like, say, MS SQL Server. I've just begun to use it on a personal project, and am very impressed.
Elevate Software support is excellent; the products solid.
Both are royalty-free. Once you license the product, you can deploy it with as many applications as you like (not all the tools, but the critical runtime bits).
Except for their client server server engines, all the database engine code compiles directly into your application. Unlike the BDE, or MS Jet (Access), there are no DLLs or OCXs to be deployed with your application.
I have used Elevate DB for just over a year as a stand-alone solution, web solution, and network, solution.
Like all DB, it has its own style here-and-there with regards to how you code up an SQL statement, however, the documentation is fabulous! They list how they deviate from standards and it is not too much off.
Support as, Wes, stated is top notch.
100% embedded if you like or stand-alone server, your choice.
Reply if you want more info
MyDAC by Devart.com are nice too. The work with MySQL, SQL Server, and almost any popular DBMS available.
A couple more questions if I may: 1) Should I create a datamodule and move all of the TTables/TQueries from the forms 2) Should I use DBISAM as opposed to ElevateDB 3) Will MyDAC replace all Delphi's and Woll2Woll's data access controls 4) Is setting ub the database as a true Client/Server more overwhelming than just using the database as multiuser
I'm not saying that I'm too 'old' to learn but I am saying that my client may not want to pay me for taking an extensive learning curve path; if you know what I mean.
A couple more questions if I may: 1) Should I create a datamodule and move all of the TTables/TQueries from the forms
[wp] For any non-trivial project, a data module is my strong preference. In fact, I use OOP inheritance, here, to prepare my application for a possible future change to the back end.
First I create a "base" data module. It has no database components on it whatsoever; just virtual; abstract declarations of the methods I'll need.
Then, from the above, I descent my "real" data module. That gets the database components, as well as the implementatio of the virtual; abstract methods in the parent.
2) Should I use DBISAM as opposed to ElevateDB
[wp] Both are good. DBISAM will probably "feel" more BDE-like to you, and it's a solid, proven database. ElevateDB, however, is more like contemporary "big gun" databases. For simple, one-off projects, I still use DBISAM. For any non-trivial new project, my strong preference is ElevateDB.
3) Will MyDAC replace all Delphi's and Woll2Woll's data access controls
[wp] Daniel has addressed that. I have no experience with MyDAC
4) Is setting ub the database as a true Client/Server more overwhelming than just using the database as multiuser
[wp] Not really, though it takes a little shift in your thinking. I could tell you an "I can't believe it" story about one very ambitious DBISAM project being deployed (against my advice) to over 200 concurrent users - in shared-file, multi-user mode. But I won't; I don't want to create the impression that I think that's ever a good idea! I would say that if you anticipate more than ten concurrent users, do yourself a favor and insist on client/server.
I'm not saying that I'm too 'old' to learn but I am saying that my client may not want to pay me for taking an extensive learning curve path; if you know what I mean.
[wp] That's a business decision for your client. For you - I'd strongly advise getting familiar with data modules and client/server database principles. You'll be well served in future projects...
A couple more questions if I may: 1) Should I create a datamodule and move all of the TTables/TQueries from the forms
DRK: This is up to you. I have seen many coders do just this with great success. I do not as I have one connection, one query object and this is all I need. When I wish to load a form with data, I formulate the appropriate SQL, return it to the query and then load my form's controls with the content of the query. So I never am concerned with what table, query I am working with as it is always just the same query.
2) Should I use DBISAM as opposed to ElevateDB
DRK: Elevate has both, though they both are sold separately. I know DBISAM is/was a great way to store data, but we went with a more SQL-centric methodology - ElevateDB. Your mileage may vary, but the more "common" we could make it, using SQL, the better our products became - we felt.
3) Will MyDAC replace all Delphi's and Woll2Woll's data access controls
4) Is setting ub the database as a true Client/Server more overwhelming than just using the database as multiuser:
DRK: A DB by its nature is multiuser. What you have to take into account is you do not lock a row, table or heaven forbid, a whole DB, at least not without a good reason.
It affords you the ability to encapsulate a number of updates in a "Transaction." Whereby if any one of the updates fails, none of the updates succeed because you "Rollback" the work.
Indexing is better. There are features you may not use, but available: Triggers, Stored Procedures/Functions, and depending on your choice: reporting, backups, replication and more.
Thanks again Wes and Daniel. I have so much to learn!
Wes the following is way beyond my current knowledge level. What do I need to do to learn what you are saying:
wp] For any non-trivial project, a data module is my strong preference. In fact, I use OOP inheritance, here, to prepare my application for a possible future change to the back end.
First I create a "base" data module. It has no database components on it whatsoever; just virtual; abstract declarations of the methods I'll need.
Then, from the above, I descent my "real" data module. That gets the database components, as well as the implementatio of the virtual; abstract methods in the parent.
Thanks so much.
I do have more questions and am so appreciative that y'all are helping. When I get to the point of being to much of a pest please let me know.
Thanks again Wes and Daniel. I have so much to learn!
[wp] That's one of the fun (or maddening) parts of our jobs; the learning never ends.
Wes the following is way beyond my current knowledge level. What do I need to do to learn what you are saying:
[wp] Whew! Where to start?
Daniel's already given you a taste of OOP, and I'll try to add something useful and not sound condescending.
At it's inception, circa 1995, Delhi was revolutionary in two areas:
1: It was a full-blown Object Oriented Development System, and
2: It was designed to be database promiscuous.
OOP makes Delphi's language much more than other languages of the time.
Sure, there were a few other products trying to fly the OOP flag, but they simply gave you a set of canned objects that you could use. Delphi took it much farther in that it let you define your own objects and extend the existing ones. This was powerful stuff.
If you ignored the OOP aspects of Delphi, well, that's sort of like buying a Ferrari and never driving it over 50 MPH. Do that for years and you miss a lot of great experiences.
OOP is so important - and it's a very large subject. There is simply no way I can give it a fair introduction in this short space.
Another important, and related topic is Design Patterns. Now, without trying to explain both, I think I can point you at an example that might start getting you excited:
In your Delphi Source folder, locate and open the Vcl\Clipbrd.pas file. This is the unit that allows Delphi programs to use the Windows clipboard.
Study the code; it's fairly straightforward. Two things are happening:
1: The Borland coders created a class (definition of an object) to represent and handle all clipboard duties.
2: They used one of the simplest, yet most powerful Design Patterns, the Singleton. There is a function outside of the class called "Clipboard" that returns a TClipboard object. It's the variable FClipboard.
Now look at the implemention of that function. Can you see what's gong on?
It implements the Singleton pattern which ensures that, at most, one - and only one - TClipboard object will ever be created in your program.
The first time you call Clipboard, the TClipboard object is created - and returned to you. But! With every subsequent call to Clipboard, that first TClipboard instance is returned. It's never created again.
The reason I bring up Design Patterns is twofold:
First, OOP really helps us implement the various design patterns,
Second, the Singleton Pattern is very useful for a Data Module. As with the Clipboard, it ensures that, at most, one - and only one - instance of your Data Module can exist during the duration of your program's session. That keeps us out of all manner of database trouble.
There are a great many books on OOP in general; and for Delphi Specifically. Really cool is that a horde of those books can be had for a song on half.com or Amazon used.
The Prestwood Knowlege Base has a lot of information about OOP, too.
Thanks so much.
I do have more questions and am so appreciative that y'all are helping. When I get to the point of being to much of a pest please let me know.
[wp] We're happy to help. Just do your part - the homework. At the very least start working through some of the example code that ships with Delphi. They're like getting an education for free.
Your design is not any different than mine, I just create everything via cod - just a personal preference.
Charlie: What, Wes, is saying is something you could do - it is not a requirement, though it is a better design.
You could just plop all your items in one DM - or several to break it up a bit more - and proceed as normal.
Wes is referring more to a paradigm of programming methodology: OOP or Object Orientated Programming.
If you search the Internet for OOP basics, you will find some great information - I just did it and immediately found some quick hits right at the top with accurate info.
In a nutshell - to quote the famous series of books "... in a nutshell" a class is referred to as a "thing" at design time an object is an instantiation of the class at run-time - you use the class or create the object
For example (using Wes' virtual idea): You might create a virtual car class You would create one or more classes inheriting from car, such as GM, Toyota, and Honda. This is called inheritance. Then when you need to use a Toyota, use create a Toyota object and it has all the methods and properties of Toyota *and* its parent, the Car Class.
TVehicle = class(TObject)
private public constructor Create; destructor Destroy; override; procedure Drive; function Turn(p_sDirection: string): boolean;
So, a caller may do: var objToyota: TToyota; objCar: TVehicle; begin { With this declaration, you now have an object, objToyota, pointing to all the things dealing with the Toyota class specifically, like "TurnOnBackupVideo" and all the public methods and properties of TVehicle, such as "Drive" } objToyota := TToyota.Create;
{ With this declaration, you only know about things in TVehicle class and know nothing about the Toyota or any other car class. But you do still have access to methods like Drive and Turn } objCar:= TVehicle.Create;
end;
If your company wants, I am sure either Wes and I know I, could be brought on in a consulting capacity to get things moving
[wp] all in code instead of with visual controls dropped on forms.
>I have zero data-aware controls - everything is built via query object and then updated the same way.
[wp] And I'm addicted to data-aware controls. The OnCreate event of my typical form will have a line of code like this:
MainDataSrc.DataSet = Dm.GetCustomerTable.
Where "Dm" is a Singleton method that returns my data module and GetCustomerTable is a data module method that makes sure the table isn't already in use, sets the desired index, and returns the table. It's little different than having the TTable (or replacement) right on the form; you simply have to remember to assign, open and close the dataset returned from the datamodule.
It is a bit more work on the front end, but I feel it offers more flexibility and extensibility as the application grows and morphs.
[wp] It's a bit of a trade off: Designing a parent data module, descending from it, and implementing all the methods seems like more work, too. But, as the application grows and morphs, all I have to do is add more methods to the data module.
The beauty of this is that, should a client want the same application, but insists on a different database, I simply create a new datamodule descendant and implement all the methhods.
Does this answer your question?
[wp] Yes. We have different design and coding preferences. Neither is "wrong."
True, to your last statement, however, what do you do if the SQL syntax changes between DB systems?
I pass everything through a SQL factory and it modifies the SQL statement according to the DB I am attached. For example, BETWEEN is different with Elevate than MySQL than SQL Server, so it must be massaged to be formatted correctly.
I have worked with DM before, just not in about 5 years or so and I agree, they are nice in many cases, however, given my choice, I prefer to not use data aware controls - just my choice
Have a great evening, Wes.
If Prestwood ever needs an extra hand (wink wink - nudge nudge)
True, to your last statement, however, what do you do if the SQL syntax changes between DB systems?
[wp] When I need to support a different database (and it doesn't happen all that often), I create a new descendant of my base data module, and...
Say the originally supported database was Microsoft Jet (Access), and now we need to change the application to support one of the more robust client/server databases.
Furrther, let's say that one of the Access data module methods invoked a particular SQL statement.
In my newly descended data module for, say SQL Server, that same method will be implemented in almost the same way, but with any necessary changes to the SQL syntax.
I pass everything through a SQL factory and it modifies the SQL statement according to the DB I am attached. For example, BETWEEN is different with Elevate than MySQL than SQL Server, so it must be massaged to be formatted correctly.
[wp] Interesting how often the Factory design pattern is showing up. I've used a data module factory that ensures the correct descendant data module gets instantiated. So in the example above, my factory would return either my Access data module, or my SQL Server data module, depending upon which database is desired..
I have worked with DM before, just not in about 5 years or so and I agree, they are nice in many cases, however, given my choice, I prefer to not use data aware controls - just my choice
[wp] There are many developers that prefer to not use data-aware controls. That's okay.
But just to keep the record clear: using a data module does not force one to use data-aware controls. Nor does using data-aware controls mean you have to use a data module.
>Have a great evening, Wes.
[wp] Thanks. It's tomorrow already, so I'll just say good day.
If Prestwood ever needs an extra hand (wink wink - nudge nudge)
[wp] Have you filled out our "register to work" form? If not,
Delphi
Print This
