dear tim,

i've changed the default engine extensions for tables, let's say from .dat
to .abc, and recompiled DBSYS putting as first lines of the project:

with Engine do begin
 active:=false;
 TableDataExtension        :='.abc';
end;

but in the opentbl unit the

Session.GetTableNames(AvailableDatabasesComboBox.Text,Items);

doesn't give back any table as result when i select a directory where there
are a lot of .abc dbisam4 files, ex-.dat.
Only if i rename the files in .dat they are shown in the
AvailableTablesListBox

It seems that GetTableNames procedure doesn't take the engine
tabledataextension value for listing table.
Is this a bug, or have i done something wrong?

Thanks in advance.

It works for me in a regular app so it's somethign with your code.

I'd suggest you double-check and make sure your extension change was not
overwritten  by some code that ran after (check Engine.TableDataExtension
right before GetTableNames)

Raul


"Alessandra" <alessandra@sarasoft.net> wrote in message
news:25A39644-A985-4129-9C20-294BC8076EEC@news.elevatesoft.com...
> dear tim,
>
> i've changed the default engine extensions for tables, let's say from .dat
> to .abc, and recompiled DBSYS putting as first lines of the project:
>
> with Engine do begin
>  active:=false;
>  TableDataExtension        :='.abc';
> end;
>
> but in the opentbl unit the
>
> Session.GetTableNames(AvailableDatabasesComboBox.Text,Items);
>
> doesn't give back any table as result when i select a directory where
> there are a lot of .abc dbisam4 files, ex-.dat.
> Only if i rename the files in .dat they are shown in the
> AvailableTablesListBox
>
> It seems that GetTableNames procedure doesn't take the engine
> tabledataextension value for listing table.
> Is this a bug, or have i done something wrong?
>
> Thanks in advance.

On related note few more suggestions:

I just noticed that dbsys.ini supports specifying data table extension
("Table Data Extension" in Engine Settings section) so my guess is that the
ReadEngineSettings overwrites your changes (depending where you made yours).

- You can just modify the ini without needing to recompile the dbsys if you
need support for custom extensions.
The only "problem" is that dbsys stores INI in the user local data location
whcih is pain to locate sometimes (on winxp it normally ends up in
%userprofile%\Local Settings\Application Data\Elevate Software\Database
System Utility\)

- or override the extension AFTER ini has been read in dbsys code

- if you have source then just change the constant   DATA_FILE_EXT =
AnsiString('.dat'); in "dbisamcn" so anything you compile will use your new
extension

Raul



"Raul" <raul@raul.ca> wrote in message
news:5846D7D8-DC56-4CA4-B283-B985461543E9@news.elevatesoft.com...
>
> It works for me in a regular app so it's somethign with your code.
>
> I'd suggest you double-check and make sure your extension change was not
> overwritten  by some code that ran after (check Engine.TableDataExtension
> right before GetTableNames)
>
> Raul
>
>
> "Alessandra" <alessandra@sarasoft.net> wrote in message
> news:25A39644-A985-4129-9C20-294BC8076EEC@news.elevatesoft.com...
>> dear tim,
>>
>> i've changed the default engine extensions for tables, let's say from
>> .dat to .abc, and recompiled DBSYS putting as first lines of the project:
>>
>> with Engine do begin
>>  active:=false;
>>  TableDataExtension        :='.abc';
>> end;
>>
>> but in the opentbl unit the
>>
>> Session.GetTableNames(AvailableDatabasesComboBox.Text,Items);
>>
>> doesn't give back any table as result when i select a directory where
>> there are a lot of .abc dbisam4 files, ex-.dat.
>> Only if i rename the files in .dat they are shown in the
>> AvailableTablesListBox
>>
>> It seems that GetTableNames procedure doesn't take the engine
>> tabledataextension value for listing table.
>> Is this a bug, or have i done something wrong?
>>
>> Thanks in advance.
>
>

Raul wrote:
> It works for me in a regular app so it's somethign with your code.
>
> I'd suggest you double-check and make sure your extension change was
> not overwritten  by some code that ran after (check
> Engine.TableDataExtension right before GetTableNames)

Hi Raul, i've double checked, and eventually found the reason: my settings
were always overridden by the

     ReadEngineSettings(AppVersionInformation,AppEngineSettings);
     SetEngineSettings(AppEngineSettings);

in the mainform.formcreate, that read/write to an ini file with all the
engine settings placed in a (very) deep user subdirectory, very difficult to
locale.

A possible workaround is to modify the engine settings manually by code
AFTER that point, and not in the first lines of the project, like i did
before.

This way, it works, but a very much cleaner solution would be to let the
user edit the ini file from the dbsys itself.

TIM: can you please add an option to the Utilities menu, to "Close and edit
..INI (engine settings)" ?

The associated procedure would be the following:

procedure TMainForm.ViewINI1Click(Sender: TObject);
var VersionInfo: TVersionInfo;
begin
ReadVersionInformation(VersionInfo);
ShellExecute(handle,'open','notepad.exe',
pchar(GetIniFileName(VersionInfo)), nil, SW_SHOWNORMAL);
close;
end;

the program would be closed, the user could reprogram the engine parameters,
saving the ini, and at the next launch DBSYS would read and use the updated
parameters. Without modifying the source and recompiling nothing.

Could you please add it, Tim?

Raul wrote:
> On related note few more suggestions:

yes Raoul, as you read, we found the same reasons and solutions. Thanks for
your kind cooperation ^_^

> Could you please add it, Tim?

One more thing, Tim: can you please add the EngineSignature to the
parameters stored/retrieved from the Ini file? otherwise i'll have to change
the dbsys source on every update to let it recognize my signature.

Thanks.. again ^_^

Alessandra,

<< TIM: can you please add an option to the Utilities menu, to "Close and
edit .INI (engine settings)" ? >>

I'll see what I can do.  There is a reason that we don't expose some of this
via the interface, namely that customers ship special configurations via the
..ini file to their customers, and they don't want their customers messing
with certain configuration settings like custom extensions.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Sorry to jump into such an old thread, but I have only just recently upgraded from 4.27 to 4.30 and find the same problem. The ini file no longer being associated with the utility (and living in same folder) is a pain. I have several projects with custom file extensions, and I used to have a local copy of dbsys (and ini) for each of them.

Now with a single ini buried way down in user's app data, it is difficult to change each time I switch projects.

I'm not set up to compile dbsys but will now probably have to hard code something to work around this, as I understand it is not safe to open tables touched by 4.30 with older executables like dbsys 4.27 (blob corruption?).

cheers,
Steve

"Tim Young [Elevate Software]" wrote:

Alessandra,

<< TIM: can you please add an option to the Utilities menu, to "Close and
edit .INI (engine settings)" ? >>

I'll see what I can do.  There is a reason that we don't expose some of this
via the interface, namely that customers ship special configurations via the
..ini file to their customers, and they don't want their customers messing
with certain configuration settings like custom extensions.

--
Tim Young
Elevate Software
www.elevatesoft.com

Steve,

<< Sorry to jump into such an old thread, but I have only just recently
upgraded from 4.27 to 4.30 and find the same problem. The ini file no longer
being associated with the utility (and living in same folder) is a pain. >>

Due to the way Windows now works in Vista and higher, I had no choice - I
had to pick a known, writable directory.

<< I'm not set up to compile dbsys but will now probably have to hard code
something to work around this, as I understand it is not safe to open tables
touched by 4.30 with older executables like dbsys 4.27 (blob corruption?).
>>

You can open the tables up using older versions, but you cannot modify them.
Doing so will corrupt the BLOB data, if the table has been updated using
4.29 or higher.

--
Tim Young
Elevate Software
www.elevatesoft.com