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)

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

"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.

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

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)
>
>

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

"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\?

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)

"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

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