Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 13 total
Thread DatabaseName/SessionName -> Database
Mon, Jun 30 2008 5:51 AMPermanent Link

Heiko Knuettel
In a global function, with no access to a TEDBSession or TEDBDatabase component, is it
possible to find out the database ("Database" property of TEDBDatabase), when the
DatabaseName and SessionName is given ?

TIA,

Heiko
Mon, Jun 30 2008 6:22 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Heiko


I certainly can't think of any way. What are you trying to achieve with this?

Roy Lambert [Team Elevate]
Mon, Jun 30 2008 6:39 AMPermanent Link

Eryk Bottomley
Roy

> I certainly can't think of any way. What are you trying to achieve with this?

Can't you just pull the session from the Engine variable using
FindSession and then the Database from the returned object using
FindDatabase?

Eryk
Mon, Jun 30 2008 7:14 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Eryk


Good one, as long as the global function has access to the engine. I really must re-read the manual obviously things didn't stick the first time.

Roy Lambert [Team Elevate]
Mon, Jun 30 2008 7:50 AMPermanent Link

Heiko Knuettel
Roy

>>What are you trying to achieve with this?

The "select * into "\memory\" issue. I try to explain...

I'm replacing them with a global function CreateMemTable(tablename, statement, index).
Global because I want to use that "migration toolkit" in different applications.

Because qualifiers are not allowed in DDL (why the hell not ??), I have to execute the
"create table as" in the memory database context, which means I need a qualifier.

memorydb: create table xyz as select * from qualifier.abc

But I have the situation that the qualifier can change (one EDBDatabase component, but
several identical databases, user can switch between them). The DatabaseName/SessionName
is always the same, but the Database changes.

So I place a special char (@) in front of every table in the statement, which is to be
replaced by the CreateMemTable() function with the current database.


The DBISAM statement

'select * into "\memory\xyz" from abc order by idx'

then would become

CreateMemTable('xyz', 'select * from @abc', 'idx');



Heiko
Mon, Jun 30 2008 8:11 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Heiko


I have the same problem. I've solved it in a slightly different way to you. I keep the sql to create the memory table in a stringlist holder and assign to the TEDBScript when the form is created

Recount.SQL.Text := StringReplace(Recount.SQL.Text, '$Disk', dm.DB.Database, [rfReplaceAll]);

You could, however, if you have access to the database at the time you call your function simply pass the name in as another parameter. You could also declare a global string variable holding the database text and alter that when the user switches between databases and pass that in as a parameter.

Is CreateMemTable a TEDBScript or a Delphi function?

Roy Lambert [Team Elevate]
Mon, Jun 30 2008 8:29 AMPermanent Link

Heiko Knuettel
Roy

>>Is CreateMemTable a TEDBScript or a Delphi function?

It's a delphi function, and that

>> simply pass the name in as another parameter.

would in fact be the easiest way. But I never thought of it...

Thanks !

Heiko
Mon, Jun 30 2008 8:51 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Heiko


>would in fact be the easiest way. But I never thought of it...

Often the case - I'm just as bad.

You may want to have a look in the extensions ng which has a script in it to create memory tables.

Roy Lambert [Team Elevate]
Mon, Jun 30 2008 12:20 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Heiko,

<< Because qualifiers are not allowed in DDL (why the hell not ??), >>

There's a lot of reasons, but most are internal reasons that deal with
issues of catalog locking and some nasty side-effects that can occur when
you're modifying the catalog of a database that is different from the
current database.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mon, Jun 30 2008 1:29 PMPermanent Link

Heiko Knuettel
Tim

>>most are internal reasons that deal with
>>issues of catalog locking and some nasty side-effects that can occur when
>>you're modifying the catalog of a database that is different from the
>>current database.

Ah...OK...sorry.

From the outside, first look, a "insert into db.abc' doesn't look more difficult to do
than a "create table db.abc", so I guessed, it must be the "it's non standard" thing
again... Smile

Heiko
Page 1 of 2Next Page »
Jump to Page:  1 2
Image