Can Dbisam 3 be modified to work in Vista? How much it would cost?
Carlos

Hi Carlos,

As far as I am aware DBISAM 3 does work with Vista.

I have some programs that still use DBISAM 3 and they work fine under Vista

Chris Holland

carlosam wrote:
> Can Dbisam 3 be modified to work in Vista? How much it would cost?
> Carlos
>

Carlos,

<< Can Dbisam 3 be modified to work in Vista? How much it would cost? >>

Possibly, and it's something that I'm looking into as part of the new
support plan that we're introducing shortly.  The bigger issue is whether I
can actually get 3.x to compile in our newer build system.  It hasn't been
compiled in our build system for several years, and so it may need a lot of
changes.

So, the answer is a very big "maybe", and with definitely no promises.
However, if fixes do become available, then they will be part of the new
support plan and will require that you be be paid up-to-date in that
respect.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Carlos,
I still have quite a significant customer base using my DBISam V3 apps under
Vista. From memory, some of the important things to look at to get your apps
ready for Vista are :

1. Ensure that your databases are created in either AppData, My Documents or
Shared Documents folder.

2. Do not use the exe folder for the session PrivateDir path. Move it to the
Windows Temp folder or any other folder that gives users full read and write
access. If your app uses "Alter Table" SQL, Restructure table or Repair
table method, then the session.PrivateDir must be set to the database folder
during that time.

3. If you have any config or ini files under the exe folder, you need to
move it elsewhere like AppData or registry etc. Basically do not attempt to
write anything to the exe folder during runtime or there will be Vista UAC
issues.

I'm in the process of porting my DBIsam v3 apps to DBISam 4. Its quite a
straight forward process. I'm still looking at EDB but I think I'll probably
end up going the DBISam route.

Regards
Gregory Sebastian

Most of us charge for our work so is fair you can also do it.

Carlos

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Carlos,

<< Can Dbisam 3 be modified to work in Vista? How much it would cost? >>

Possibly, and it's something that I'm looking into as part of the new
support plan that we're introducing shortly.  The bigger issue is whether I
can actually get 3.x to compile in our newer build system.  It hasn't been
compiled in our build system for several years, and so it may need a lot of
changes.

So, the answer is a very big "maybe", and with definitely no promises.
However, if fixes do become available, then they will be part of the new
support plan and will require that you be be paid up-to-date in that
respect.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Gregory Sebastian" <gregorys@ezysoft-dev.com> wrote:


>>1. Ensure that your databases are created in either AppData, My Documents or
>>Shared Documents folder.

I usually locate my data on .\data folder so the data is on Program Files\myprogram\data
When a workstation look for the data it will find it on the .\data folder
How can I configure so the workstation find the data on the Server computer AppData?
Could you give me an example?


>>2. Do not use the exe folder for the session PrivateDir path. Move it to the
>>Windows Temp folder or any other folder that gives users full read and write
>>access. If your app uses "Alter Table" SQL, Restructure table or Repair
>>table method, then the session.PrivateDir must be set to the database folder
>>during that time.

>>3. If you have any config or ini files under the exe folder, you need to
>>move it elsewhere like AppData or registry etc. Basically do not attempt to
>>write anything to the exe folder during runtime or there will be Vista UAC
>>issues.

Could you give me an example how to set a local data on the workstation so
I can configure that workstation independent from the server. (NOT USE THE AppData of the
server)


Thanks

Carlos

Hi Carlos,
>> the data is on Program Files\myprogram\data
This will result in problems for the user in a default installation of Vista

The APPData folder is hidden by default so I don't use it myself to store
user database. If the user needs to backup or administer the data folder,
they will have to know where to look for it then un-hide it. In my case, I
either use either My Documents (current user only) or Shared Document
folder.

Sample code for Delphi is :

function GetSpecialFolder(const CSIDL : integer) : string;
var RecPath : PAnsiChar;
begin
 RecPath := StrAlloc(MAX_PATH);
 try
   FillChar(RecPath^,MAX_PATH,0);
   if SHGetSpecialFolderPath(0,RecPath,CSIDL,false) then
   begin
     result := RecPath;
   end
   else
     result := '';
 finally
   StrDispose(RecPath);
 end;
end;

Some common values for CSIDL are :

CSIDL_COMMON_DOCUMENTS          0x002e
CSIDL_MYDOCUMENTS               0x000c
CSIDL_LOCAL_APPDATA             0x001c
CSIDL_COMMON_APPDATA            0x0023

You can search the rest of the constants on the web. I believe that
SHGetSpecialFolderPath is now deprecated but it is backward compatible with
XP and earlier so I still use it for time being. Please thoroughly test
before using.

Regards
Gregory Sebastian








"carlosam" <carlos.aneses@gmail.com> wrote in message
news:20E6C366-CAC2-4202-ADE6-A421D1EC00A4@news.elevatesoft.com...
> "Gregory Sebastian" <gregorys@ezysoft-dev.com> wrote:
>
>
>>>1. Ensure that your databases are created in either AppData, My Documents
>>>or
>>>Shared Documents folder.
>
> I usually locate my data on .\data folder so the data is on Program
> Files\myprogram\data
> When a workstation look for the data it will find it on the .\data folder
> How can I configure so the workstation find the data on the Server
> computer AppData?
> Could you give me an example?
>
>
>>>2. Do not use the exe folder for the session PrivateDir path. Move it to
>>>the
>>>Windows Temp folder or any other folder that gives users full read and
>>>write
>>>access. If your app uses "Alter Table" SQL, Restructure table or Repair
>>>table method, then the session.PrivateDir must be set to the database
>>>folder
>>>during that time.
>
>>>3. If you have any config or ini files under the exe folder, you need to
>>>move it elsewhere like AppData or registry etc. Basically do not attempt
>>>to
>>>write anything to the exe folder during runtime or there will be Vista
>>>UAC
>>>issues.
>
> Could you give me an example how to set a local data on the workstation so
> I can configure that workstation independent from the server. (NOT USE THE
> AppData of the
> server)
>
>
> Thanks
>
> Carlos
>

How can I know the local computer from the server on the common CSIDL?

Carlos

"Gregory Sebastian" <gregorys@ezysoft-dev.com> wrote:

Hi Carlos,
>> the data is on Program Files\myprogram\data
This will result in problems for the user in a default installation of Vista

The APPData folder is hidden by default so I don't use it myself to store
user database. If the user needs to backup or administer the data folder,
they will have to know where to look for it then un-hide it. In my case, I
either use either My Documents (current user only) or Shared Document
folder.

Sample code for Delphi is :

function GetSpecialFolder(const CSIDL : integer) : string;
var RecPath : PAnsiChar;
begin
 RecPath := StrAlloc(MAX_PATH);
 try
   FillChar(RecPath^,MAX_PATH,0);
   if SHGetSpecialFolderPath(0,RecPath,CSIDL,false) then
   begin
     result := RecPath;
   end
   else
     result := '';
 finally
   StrDispose(RecPath);
 end;
end;

Some common values for CSIDL are :

CSIDL_COMMON_DOCUMENTS          0x002e
CSIDL_MYDOCUMENTS               0x000c
CSIDL_LOCAL_APPDATA             0x001c
CSIDL_COMMON_APPDATA            0x0023

You can search the rest of the constants on the web. I believe that
SHGetSpecialFolderPath is now deprecated but it is backward compatible with
XP and earlier so I still use it for time being. Please thoroughly test
before using.

Regards
Gregory Sebastian








"carlosam" <carlos.aneses@gmail.com> wrote in message
news:20E6C366-CAC2-4202-ADE6-A421D1EC00A4@news.elevatesoft.com...
> "Gregory Sebastian" <gregorys@ezysoft-dev.com> wrote:
>
>
>>>1. Ensure that your databases are created in either AppData, My Documents
>>>or
>>>Shared Documents folder.
>
> I usually locate my data on .\data folder so the data is on Program
> Files\myprogram\data
> When a workstation look for the data it will find it on the .\data folder
> How can I configure so the workstation find the data on the Server
> computer AppData?
> Could you give me an example?
>
>
>>>2. Do not use the exe folder for the session PrivateDir path. Move it to
>>>the
>>>Windows Temp folder or any other folder that gives users full read and
>>>write
>>>access. If your app uses "Alter Table" SQL, Restructure table or Repair
>>>table method, then the session.PrivateDir must be set to the database
>>>folder
>>>during that time.
>
>>>3. If you have any config or ini files under the exe folder, you need to
>>>move it elsewhere like AppData or registry etc. Basically do not attempt
>>>to
>>>write anything to the exe folder during runtime or there will be Vista
>>>UAC
>>>issues.
>
> Could you give me an example how to set a local data on the workstation so
> I can configure that workstation independent from the server. (NOT USE THE
> AppData of the
> server)
>
>
> Thanks
>
> Carlos
>

Gregory Sebastian wrote:

>
> The APPData folder is hidden by default so I don't use it myself to
> store user database. If the user needs to backup or administer the
> data folder, they will have to know where to look for it then un-hide
> it. In my case, I either use either My Documents (current user only)
> or Shared Document folder.
>

I do use the commonappdata folder tree .. and get round the hidden bit
by adding a link to my parent folder in my application's About Box.
The user just has to click...

Malcolm

> How can I know the local computer from the server on the common CSIDL?
I'm not sure myself Carlos, sorry.  You need to do some Googling or search
MSDN .  If you find out, please post back here. I'm keen to know, thanks.

Regards
Gregory Sebastian