Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 10 total |
tips and hints to convert from Paradox |
Mon, Feb 20 2006 7:54 AM | Permanent Link |
"Santy Concepción" | Hi!
After a few months trying DBISAM, we are going to convert our old Parado/BDE applicatoin to DBISAM. Are there any inconveniences, tips, hints, things to be careful with, etc...? Thanks!! |
Mon, Feb 20 2006 9:01 AM | Permanent Link |
Dan Rootham | Santy,
<< After a few months trying DBISAM, we are going to convert our old Parado/BDE applicatoin to DBISAM. Are there any inconveniences, tips, hints, things to be careful with, etc...? >> It's along time since I converted from Paradox to DBISAM, but I do remember that we had problems with accented characters getting trashed in Portuguese, German etc. Might be worth running some tests to make sure that the import does preserve the non-ASCII characters. Some of the Paradox language drivers were... interesting. HTH, Dan |
Mon, Feb 20 2006 9:07 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Santy
Do the conversion in the first instance just by going a global search and replace on the component names. Avoid OnFilter event if possible. If using threads make sure you observe the rules in the manual, if not prepare for disaster! Check all SQL - DBISAM is better but more stringent than Paradox/BDE (double quote vs single quote for example) Generally though it should be fairly simple. Roy Lambert |
Mon, Feb 20 2006 12:38 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dan,
<< It's along time since I converted from Paradox to DBISAM, but I do remember that we had problems with accented characters getting trashed in Portuguese, German etc. Might be worth running some tests to make sure that the import does preserve the non-ASCII characters. Some of the Paradox language drivers were... interesting. >> That's probably the transliterate issue - you had to make sure to check the Transliterate check box in the BDE Database Transfer Utility in order to keep the high ASCII characters during the conversion. Also, I believe that initially (way back when , BDETran didn't have a transliterate option. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Feb 20 2006 4:16 PM | Permanent Link |
"Adam H." | Another one for the list...
Make sure you optimise your queries by adding indexes for the fields that you will use. In Paradox with the BDE, we were allowed to remain sloppy, because I believe the BDE created some indexes on the fly (?) in order to execute the query fast. With DBISam, if you don't optimise your queries, you will see a very noticeable difference in time on larger tables. It's easy to fix, but just one to be aware of. Apart from that - You'll love DBISam. Seriously. (I've come from the same background as you!) I'm doing things in Queries I could have never done before with the BDE. Some of my faviourites are Memory queries, allowing me to do "queries on queries", and the ability to perform multiple SQL queries in the one component (by seperating each query with the semicolumn delimiter ';') Oh, and the fact that their are no additional engines, DLL's, installations, etc to worry about - that DBISam compiles direct into your exe - no more configuration required - that rocks! Tim - out of curiosity, did I read somewhere that ElevateDB will create Indexes on the fly, to automatically optimise queries? Cheers Adam. |
Tue, Feb 21 2006 12:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< Tim - out of curiosity, did I read somewhere that ElevateDB will create Indexes on the fly, to automatically optimise queries? >> Actually, no. However, if you use the constraints properly, then most tables will already have primary, unique, and foreign keys on all of the important columns already, hence joins and searching will be fast. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Feb 21 2006 1:22 PM | Permanent Link |
"Jose Eduardo Helminsky" | Tim
I understand you point but I think that sometimes we need to query using a "non-important" field and in that way the speed will be slow. It will be a good feature for ElevateDB. Eduardo |
Tue, Feb 21 2006 3:49 PM | Permanent Link |
"Santy Concepción" | Ho, Roy...
Why to avoid using OnFilter event? We have a search option that uses this event in our app. "Roy Lambert" <roy.lambert@skynet.co.uk> escribió en el mensaje news:3A96CE2E-5F45-412D-89C9-DE10D27F1564@news.elevatesoft.com... > Santy > > > Do the conversion in the first instance just by going a global search and > replace on the component names. > > Avoid OnFilter event if possible. > > If using threads make sure you observe the rules in the manual, if not > prepare for disaster! > > Check all SQL - DBISAM is better but more stringent than Paradox/BDE > (double quote vs single quote for example) > > Generally though it should be fairly simple. > > > Roy Lambert > |
Tue, Feb 21 2006 7:01 PM | Permanent Link |
"Adam H." | Hi Santy,
I think the idea is, if you can do a filter / query any other way, do it another way, but if not, use the onfilter event. The onfilter event, IIRC - needs to load every record in the table / result before it does the query, and does not use the speed benefits you obtain with indexes. This will slow down your application (as it always has). If you're happy with the speed you currently get out of the onfilterevent, you probably won't have a problem, unless your data grows significantly. Regards Adam. |
Wed, Feb 22 2006 6:27 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eduardo,
<< I understand you point but I think that sometimes we need to query using a "non-important" field and in that way the speed will be slow. It will be a good feature for ElevateDB. >> I understand, however there are issues with creating indexes "on the fly" in a multi-user scenario that are very difficult to overcome given the current architecture. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |