![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 11 total |
![]() |
Tue, Sep 11 2007 12:02 PM | Permanent Link |
"Avalon" | For you users of the "old" version. I've just found an annoying problem
using 3.30 under Vista, which required 6 hrs of investigation to solve. Master/detail tables, when detail uses a double-or-multiple-field index (for example an integer key to refer to master field + a date field to obtain a date-sorted detail record list) simply don't work: details results always empty. The same table/procedure under XP works fine. The solution: check the "XPSP2" checkbox under the executable properties, and all works again. Anyone has an explanation for such problem? Note that using a single-field index for detail works fine even under Vista. Avalon |
Tue, Sep 11 2007 2:22 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | << For you users of the "old" version. I've just found an annoying problem
using 3.30 under Vista, which required 6 hrs of investigation to solve. >> Just for the record 3.x is old. It has been frozen now for 3 years. << Master/detail tables, when detail uses a double-or-multiple-field index (for example an integer key to refer to master field + a date field to obtain a date-sorted detail record list) simply don't work: details results always empty. The same table/procedure under XP works fine. The solution: check the "XPSP2" checkbox under the executable properties, and all works again. Anyone has an explanation for such problem? Note that using a single-field index for detail works fine even under Vista. >> What language and sort are you using for the table(s) in question ? -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Sep 11 2007 8:33 PM | Permanent Link |
"Avalon" | Tim Young [Elevate Software] wrote:
> What language and sort are you using for the table(s) in question ? sort: "default sort order", language "italian" (assigned by default when i created the table, i guess ; anyway my OS is in italian). May the language be the key to the mistery? The problem showed up both on an english-localized Vista and an italian one, while on XP those indexes worked fine. By the way i know that 3.30 *is* old, but the effort to convert/upgrade all our complex management applications to EDB would be too much, especially considering the need to deploy specific database-conversion procedures, teach hundreds of customers to run them, deploy and test the new apps, with the need to adjust here and there due to the new features of EDB etc. - and in the end applications would run exactly as 3.30 ones, with no major advantages for customers. Avalon |
Wed, Sep 12 2007 3:02 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Avalon
"would run exactly as" ... "with no major advantages for customers" Congratulations - I think you have almost perfectly described updating to Vista ![]() Roy Lambert ps you have missed out more slowly and more awkwardly though |
Wed, Sep 12 2007 7:43 AM | Permanent Link |
"Robert" | "Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message news:674BA0B4-913F-4E5A-AC7B-01A8F97561D5@news.elevatesoft.com... > Avalon > > > "would run exactly as" ... "with no major advantages for customers" > > Congratulations - I think you have almost perfectly described updating to > Vista ![]() > > Roy Lambert > > ps you have missed out more slowly and more awkwardly though True, but you know it's useless to fight these robber barons like Bill Gates or Tim. They use their immense financial power to force you to upgrade, sooner or later. Seriously, I'm testing Vista in preparation for my customers starting to upgrade. My personal opinion on Vista vs XP is irrelevant. If the customers upgrade, I have to be ready. DBISAM V3 had pretty mcuh all the functionality I needed, but it had a couple of nasty bugs that would never get fixed, plus IMO running with a database that is not supported anymore is unacceptable, so I had to bite the bullet and upgrade. Robert |
Wed, Sep 12 2007 1:08 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | << sort: "default sort order", language "italian" (assigned by default when i created the table, i guess ; anyway my OS is in italian). May the language be the key to the mistery? >> It's possible, but I don't know for sure. I'm going to do some tests here on a Vista test machine (we don't actually use Vista yet) and see if I can replicate it just to see what the exact cause is. << By the way i know that 3.30 *is* old, but the effort to convert/upgrade all our complex management applications to EDB would be too much, especially considering the need to deploy specific database-conversion procedures, teach hundreds of customers to run them, deploy and test the new apps, with the need to adjust here and there due to the new features of EDB etc. - and in the end applications would run exactly as 3.30 ones, with no major advantages for customers. >> That's actually not true. EDB has many advantages over DBISAM in terms of less chance of corruption of the database structures due to the new catalog format, faster repairs (if necessary), faster execution of queries and filters, better/faster remote operation, better EDB Manager for interactively working with databases, etc. As for migration, the DBISAM 3.x -> EDB migration is very simple to execute, and can be done from within the new EDB application itself. It is definitely true that a conversion from DBISAM 3.x to EDB is not exactly a light undertaking, but there are many good reasons for doing so, not the least of which is that you won't be out in the cold in terms of support. There's really only so much we can do for you if you're using DBISAM 3.x or older. Even upgrading to DBISAM 4.x would be an improvement in terms of our ability to support you. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Sep 12 2007 1:38 PM | Permanent Link |
"Avalon" | Tim Young [Elevate Software] wrote:
> It's possible, but I don't know for sure. I'm going to do some > tests here on a Vista test machine (we don't actually use Vista yet) > and see if I can replicate it just to see what the exact cause is. Thanks Tim! it would also be interesting to know what the Vista "XP SP 2 compatibility mode" involves for applicazions (locales, others?). Probably it's documented somewhere, but have no time to search for it. > That's actually not true. EDB has many advantages over DBISAM in > terms of less chance of corruption of the database structures due to > the new catalog format, faster repairs (if necessary), we sell a separate specific application for automated backups of our customers data, and give maintenance/repair service on request, so a more reliable database to us would mean only paradoxally a loss of money (semiserious grin). > faster > execution of queries and filters, better/faster remote operation, > better EDB Manager for interactively working with databases, etc. > As for migration, the DBISAM 3.x -> EDB migration is very simple to > execute, and can be done from within the new EDB application itself. yes i'm aware of all these features, i've followed the developement and find EDB definitely a great product as of features, documentations and support, but the leap in terms of code adaptations is too high, and we can't ask for such upgrade any money to our customers, so at least for legacy applications we'll continue with 3.30 until possible. For future new applications i'd rather prefer to jump to EDB instead of passing through the pain of upgrading to 4.x and then EDB, but at the moment we're mainly supporting and developing legacy apps, and haven't in target any new app, so the decision is rather in the future. Avalon |
Wed, Sep 12 2007 1:40 PM | Permanent Link |
"Avalon" | Roy Lambert wrote:
> "would run exactly as" ... "with no major advantages for customers" > > Congratulations - I think you have almost perfectly described > updating to Vista ![]() or D2007, actually ![]() upgrade to it, let's see the news with the next Highlander) > ps you have missed out more slowly and more awkwardly though yes lol Avalon |
Thu, Sep 13 2007 3:14 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Avalon,
<< Thanks Tim! it would also be interesting to know what the Vista "XP SP 2 compatibility mode" involves for applicazions (locales, others?). Probably it's documented somewhere, but have no time to search for it. >> I've looked and looked, and so far I haven't found any definitive MS paper on it like what they had for the Win32 -> .NET API conversion chart. << we sell a separate specific application for automated backups of our customers data, and give maintenance/repair service on request, so a more reliable database to us would mean only paradoxally a loss of money (semiserious grin). >> No comment. ![]() -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jan 11 2008 6:29 PM | Permanent Link |
Jan Hornstrup | Hi Avalon.
It is correct, that checking the XPSP2 will solve all strange behaivor of DBISAM-3 tables and SQL. BUT - BUT - BUT unfortunately this features is not enabled, when the executeable program is stored on a shared network drive. It only work, when the program is on a local harddrive !!! If you have any solution to this, PLEASE let me know as I also have 100's of installations to update. Brgds Jan Hornstrup Denmark Email: jhc@soft-team.dk "Avalon" <funny@funny.com> wrote: For you users of the "old" version. I've just found an annoying problem using 3.30 under Vista, which required 6 hrs of investigation to solve. Master/detail tables, when detail uses a double-or-multiple-field index (for example an integer key to refer to master field + a date field to obtain a date-sorted detail record list) simply don't work: details results always empty. The same table/procedure under XP works fine. The solution: check the "XPSP2" checkbox under the executable properties, and all works again. Anyone has an explanation for such problem? Note that using a single-field index for detail works fine even under Vista. Avalon |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |