Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 20 of 20 total |
Prodigal return to fold? |
Mon, May 31 2010 8:04 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
>For me the main issue I face is multiple queries and selecting into >Memory tables, and then doing queries from those memory tables. (You >should see some of my SQL statements - there very complex That was one of my prime hatreds. Tim helped with a script to which I simply pass the query and it does the rest. It works and the script takes most of the sting out of the conversion but I still prefer DBISAM's syntax. You'll probably find that the SQL 2012 standard will introduce it I'd also just got my head round using JOIN in DELETE statements and had to learn a new syntax. It was all very hard on my poor old brain. With my current knowledge I don't think the conversion would have been to bad but with my experience of SQL limited to DBISAM it was tricky on occasions. I think you two are probably choosing a good approach but I would recommend doing the conversion once you've had some practice using ElevateDB. Roy Lambert |
Tue, Jun 1 2010 8:51 AM | Permanent Link |
Matthew Jones | Can I just clarify this please? Let's say I have two apps, A and B. From your
option 3, I should be able to have each with completely independent setups for their catalog (config) files yes? So I'd have A run, see there is no catalog, and create it (presumably EDB allows me to start a new one from code). It could then set up a database to have the files in a directory that is for A only, and it could get on with things nicely. Likewise when B turns up, it could be completely independent. Does the EDB data manager make it easy to do the reverse coding as DBISAM used to? And is EDB tolerant of databases being deleted, and allowing the code to re-create the table? One of my apps uses this a lot... /Matthew Jones/ |
Tue, Jun 1 2010 9:50 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Matthew
>Can I just clarify this please? Let's say I have two apps, A and B. From your >option 3, I should be able to have each with completely independent setups for >their catalog (config) files yes? So I'd have A run, see there is no catalog, and >create it (presumably EDB allows me to start a new one from code). It could then >set up a database to have the files in a directory that is for A only, and it could >get on with things nicely. Likewise when B turns up, it could be completely >independent. Yes - Providing you have set up unique names for the configuration file. Think of the configuration file as the database of databases. It hold information about what databases you have in the app, what users etc. The catalog file (and you can have several to an configuration) holds details about a database and its associated tables. ALL the catalog files will have the same name (or at least I can only see one place in the session to set it). However if you choose to name all your configuration files matthew.config do not blame me for the catastrophe that will occur. >Does the EDB data manager make it easy to do the reverse coding as DBISAM used to? Yes and no Click a couple of buttons and EDBManager will reverse engineer the database. If you want just a table you have to cut'n'paste (Tim has promised - I think - a single table option). There are more elements possible because the indexing's a bit different and you can have things like triggers, functions etc. Also you can't use the table reverse engineer code in isolation. It has to be used in the context of a database. >And is EDB tolerant of databases being deleted, and allowing the code to re-create >the table? This is where we have to be careful with the meaning of words like database. In ElevateDB there is a catalog file which is to all intents and purposes the database. The other files are simply to hold data/indices. ALL the definitions are in the catalog. If you delete the table files at the OS level then ElevateDB will recreate them empty when you first attempt to access them (I use this as a cheat to save me from having to DELETE FROM my tables when importing the live data back into my development system). If you delete the catalog file then having the table files around will do you no good because you can't access them. The best you can do is create a new catalog and (hopefully) point it at the tables. Its easy enough to create a system from scratch in code (generally using the reverse engineered code from EBDManager unless you're a masochist). Its also easy to DROP TABLE and then later on CREATE TABLE. The main thing being to get the context right - ie make sure you're in the right session/database when you do it. >One of my apps uses this a lot... Deliberately? Roy Lambert [Team Elevate] |
Tue, Jun 1 2010 3:11 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gregory,
<< The thing that stops me going furthur with EDB on both occasions is the deployment of the EDB Config file. I could not find a way to programmatically deploy the Config file in a multiuser workgroup enviroment. The only way I can see it being done is to allow the end user to point to the config file path on a shared network folder from within my app. >> I already have difficulty guiding some users via email/ web to open their DB from a network shared folder. This was all that was required in DBISam but in EDB, I will probably have to help users point to the Config file as well from all workstations. This could also put off some end-users not to mention the increased support cost for me. I'm concerned that some of my existing customers may not want to purchase my new EDB driven product just because of this additional configuration required on their part. From their point of view, my new version would be a step back. Most of them won't benefit from the Unicode support and none of them will benefit from the new SQL support. >> A new feature is going into the next 2.03 B14 build that will allow the use of relative paths for databases, with relative in this case meaning "relative to the location of the configuration file". This will allow you to simply specify the configuration file path, and then have the database paths all be specified as relative to the absolute path used by the configuration like this: TEDBEngine.ConfigPath = m:\myapp MyDatabase = CREATE DATABASE MyDatabase PATH 'data' ElevateDB will then look in the m:\myapp\data directory for the MyDatabase catalog and tables. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jun 1 2010 3:12 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gregory,
<< What about in Remote sesssions. In DBISam we only need to specify the hostname/port or IP address/port to connect to the DBISam server. In EDB, is the Config file relevant on the client side application as well or only on the server side ? >> It's only relevant on the server side and for local sessions on the client side, and is ignored for remote sessions on the client side. Just like with DBISAM. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jun 1 2010 3:13 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gregory,
BTW, this excellent feature request was made by Rob Frye. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jun 1 2010 7:01 PM | Permanent Link |
Adam H. | Hi Roy,
> I think you two are probably choosing a good approach but I would recommend doing the conversion once you've had some practice using ElevateDB. I would love to do that, but unfortunately I don't believe that will be possible in my situation. We're talking 300+ queries, with many of them extremely complex. (I tried the conversion script but the conversion didn't work - presumably because of their complexity). These are queries that may have 12 or more queries within them, with multiple "select into memory" statements, and then other queries selecting from those with joins to physical tables into other queries, etc. Some of these took me hours to get right (for just a single query) and two of these application have taken over 4 years of development - so I envisage the time it would take to convert these larger applications to EDB will be too cost prohibited. (Especially when the end client will notice no difference from a user perspective). I think my only options are to either keep DBISam for all applications, or keep DBISam within these older applications and start using EDB for all future apps. I think the latter is the better option. (Of course, my fingers are crossed that maybe one day EDB may introduce some options for "select into memory" and the like with EDBQueries... but that's very wishfull thinking. Cheers Adam. |
Tue, Jun 1 2010 8:52 PM | Permanent Link |
Gregory Sebastian | Thanks Tim,
Will probably try EDB again for my own internal projects before trying it in my commercial products. Regards Gregory Sebastian |
Wed, Jun 2 2010 2:16 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
Without seeing the queries I can only say you're proabably right. I'd guess that anything that mixes DBISAM style scripts and SELECT INTO memory tables is a no go for simple conversion. Roy Lambert [Team Elevate] |
Wed, Jun 2 2010 4:57 AM | Permanent Link |
Matthew Jones | Many thanks Roy. To know that these are all possible gives confidence.
And yes, the support people for one of my apps get a little trigger happy, but the data in the tables has a lifetime of about 3 minutes, so if it is failing for some reason they often delete them to clear it all out and my app re-populates and carries on. Obviously not a common use of a database, but it is a very nice way to handle massively multi-threaded data access. /Matthew Jones/ |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |