Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 13 total |
DatabaseName/SessionName -> Database |
Mon, Jun 30 2008 5:51 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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... Heiko |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, May 23, 2024 at 03:39 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |