Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 10 total |
DBISAM Error with v4 and Windows Vista (Pro & Ultimate)? |
Tue, Sep 11 2007 4:13 PM | Permanent Link |
Ron P | I have received two customer reports for this. One was using Vista Pro, the other Vista "Ultimate".
The program was compiled with Delphi 7 and DBISAM 4.14. First they get: DBISAM Engine Error #12035. The table rrmarks is not the correct version. Followed by: DBIAMAMRR2m Cannot perform this operation on a closed dataset. (this is a different table) Additional oddities/info: - The table is definitely the correct version. - The error does not occur in XP/Win2000/98 - I have Vista Home Basic installed on a laptop and have NOT been able to reproduce this error. I have installed as Administrator and Standard User with UAC enabled. - Beta tester with Vista Home was also not able to reproduce error. - An earlier version of the application with DBISAM 3.27 worked for at least one of the customers. - Changing the compatibility mode for the application did not solve the problem - The table is not being altered in any way by the application. - It does not appear that the tables are corrupted (MD5 checksum verified) |
Wed, Sep 12 2007 1:10 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ron,
<< I have received two customer reports for this. One was using Vista Pro, the other Vista "Ultimate". The program was compiled with Delphi 7 and DBISAM 4.14. First they get: DBISAM Engine Error #12035. The table rrmarks is not the correct version. Followed by: DBIAMAMRR2m Cannot perform this operation on a closed dataset. (this is a different table) >> Is this on a Vista-only peer-to-peer network where the table resides on a different machine ? -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Sep 12 2007 2:44 PM | Permanent Link |
Ron P | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
<<Is this on a Vista-only peer-to-peer network where the table resides on a different machine ?>> No. the tables reside on the same machine. |
Thu, Sep 13 2007 3:17 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ron,
<< No. the tables reside on the same machine. >> Hmm, the only thing I'm aware of with Vista is an issue with the new version of the SMB protocol present in Vista, which only applies with network connections to other Vista machines. I'll have to keep checking around to see if there are any other file read/write issues that could cause this type of issue. I would, however, suggest that you upgrade to the latest DBISAM 4.25 version if you are still using 4.14. That way we can at least work from a known point of stability. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Sep 13 2007 7:07 PM | Permanent Link |
"Huhtaman" | Ron:
This may not be the issue - but it is good to rule "Virtualization" out as a problem. Vista also implements "virtualization" if you do not code around this "feature". Virtualization is designed to protect files stored in protected areas of the disk such as under program files. What happens is that all file changes are recorded to a "virtual" area of the disk and the original files are left intact. Your program is then directed to run on the virtualized files. However, this feature is buggy and unstable and unpredictable. If you put your data under a protected area of the disk without disabling the UAC (User Account Controls) then virtualization happens by dafault. It can also be halted by including a "manifesto" in you executable. You can search the newsgroups for more specifics. "Ron P" <rwystation@yahoo.com> wrote in message news:4B2CD07A-3402-4FE4-BB0E-6540AB1CE06D@news.elevatesoft.com... >I have received two customer reports for this. One was using Vista Pro, the >other Vista "Ultimate". > The program was compiled with Delphi 7 and DBISAM 4.14. > > First they get: DBISAM Engine Error #12035. The table rrmarks is not the > correct version. > Followed by: > DBIAMAMRR2m Cannot perform this operation on a closed dataset. > (this is a different table) > > Additional oddities/info: > - The table is definitely the correct version. > - The error does not occur in XP/Win2000/98 > - I have Vista Home Basic installed on a laptop and have NOT been able to > reproduce this error. I have installed as Administrator and Standard User > with UAC enabled. > - Beta tester with Vista Home was also not able to reproduce error. > - An earlier version of the application with DBISAM 3.27 worked for at > least one of the customers. > - Changing the compatibility mode for the application did not solve the > problem > - The table is not being altered in any way by the application. > - It does not appear that the tables are corrupted (MD5 checksum verified) > > |
Fri, Sep 14 2007 2:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Neil,
<< This may not be the issue - but it is good to rule "Virtualization" out as a problem. >> Good point, I forgot about that "feature". -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Sep 18 2007 6:54 PM | Permanent Link |
Ron P | "Huhtaman" <nhuhta@digital.net> wrote:
<< This may not be the issue - but it is good to rule "Virtualization" out as a problem.>> MEGO - My Eyes Glaze Over. It's not that I'm a novice - the problem is I'm too old for all this newfangled stuff. The big question for me is: Why doesn't it happen in Vista Home Basic? Is UAC different in that version? Now for the part that demonstrates my ignorance. In this application version, all of the files are installed into a sub-folder of \Program Files\. The app gets the path to the tables with "ExtractFilePath(Application.ExeName)". Am I correct that Windows Vista UAC may find this naughty? Can users safely work around this by installing to a folder that is not in \Program Files\? |
Wed, Sep 19 2007 6:09 AM | Permanent Link |
Chris Erdal | Ron P <rwystation@yahoo.com> wrote in
news:AFA67F7C-1287-491C-BDB9-345EAF4BD687@news.elevatesoft.com: Can users safely work around this by > installing to a folder that is not in \Program Files\? I've set up a common function for my programs, for use with XP - I've not yet had to deal with Vista though: function AllUsersDataDir: string; begin Result := GetEnvironmentVariable('ALLUSERSPROFILE') + '\' + ExtractFileName(GetEnvironmentVariable('APPDATA')) + '\'; end; and then I use it like this: function TDataModule1.BackupDir: string; begin Result := AllUsersDataDir + 'ErdalSoft\'+ ChangeFileExt(ExtractFileName(ParamStr(0)),'')+'\Backup\'; end; maybe you could do something similar? -- Chris Erdal (hence "ErdalSoft" !) (XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.04 build 3) |
Wed, Sep 19 2007 3:24 PM | Permanent Link |
"Robert" | "Huhtaman" <nhuhta@digital.net> wrote in message news:5461141D-9C97-47DB-8899-3D4B560E516B@news.elevatesoft.com... > Ron: > > This may not be the issue - but it is good to rule "Virtualization" out > as a problem. > > Vista also implements "virtualization" if you do not code around this > "feature". Virtualization is designed to protect files stored in protected > areas of the disk such as under program files. What happens is that all > file Thanks, I was pulling my hair trying to understand where my INI file (created the first time I execute the program) had ended up. If you install in a network drive (the usual case with me) seems to work just like XP (and like DOS, yeah!) There has to be a better way to run network programs than this Vista monstrosity. Each workstation should not be duplicating all this code. BTW, I noticed that Elevate installs right off the C: drive, not in programs. Wise man, this Tim. Robert |
Thu, Sep 20 2007 2:01 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< There has to be a better way to run network programs than this Vista monstrosity. Each workstation should not be duplicating all this code. BTW, I noticed that Elevate installs right off the C: drive, not in programs. Wise man, this Tim. >> Well, I wish I could claim credit for seeing Vista coming, but it was really just the age of DBISAM showing a little bit. Originally we did it that way to allow for installation on network drives, particularly Novell Netware, where long file names and Program Files folders might not exist. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |