On 2/4/2015 10:35 AM, Roy Lambert wrote:
> Almost right You don't need to open the configuration database, just make sure that the TEDBQuery you use has Configuration set as the database. Or at least that's what happened when I tried it.

Good point and saves time.

> Not too sure I fully agree with this statement. Whilst you don't need to instantiate database components the app does need to know about the databases and is told about them by the configuration file.

It  depends on your definition of "app knowing" - there is no
"technical" need for app to reference any database or table or such
thing. It can look these things up but it does not have to use it in
normal sense.

Generic interactive SQL utility that takes SQL from user and just runs
it (and would pass the error back to user) would not need to know much
and would work with just session, query and configuration database.

Any other sql building utility or db management app also might treat the
database objects just as pick-list items without caring much about data
content.

LOB apps yes would need to make some assumption about db and table
structures and names etc - even if they create them runtime.

The really cool thing is that EDB architecture does let you write all of
these apps.

Raul

Raul

>It depends on your definition of "app knowing" - there is no
>"technical" need for app to reference any database or table or such
>thing. It can look these things up but it does not have to use it in
>normal sense.

OK - I accept that - just be sure to let me know when you can run an app without a configurations file - creating one at run time will be regarded as cheating and punishable by death

>Generic interactive SQL utility that takes SQL from user and just runs
>it (and would pass the error back to user) would not need to know much
>and would work with just session, query and configuration database.
>
>Any other sql building utility or db management app also might treat the
>database objects just as pick-list items without caring much about data
>content.

As far as the user is concerned that's essentially what my query builder does. They don't need to know table names or relationships just pick from lists (poor souls have to type in the selection criteria though)

>LOB apps yes would need to make some assumption about db and table
>structures and names etc - even if they create them runtime.

Being truely wicked here the implication is that for non-LOB apps you can type random SQL in and it will work - hmmmm

>The really cool thing is that EDB architecture does let you write all of
>these apps.

Nah - what would be  a really cool thing would be if it wrote them for me

Roy

On 2/4/2015 11:30 AM, Roy Lambert wrote:
> Being truely wicked here the implication is that for non-LOB apps you can type random SQL in and it will work - hmmmm

Sure. Take EDBManager for example - i can type any SQL into it an it
just works (does not even have to be sql). Either error or results get
reported back and in my book this means EDB just works (though there
might be a problem between chair and keyboard in case of errors - not
EDB fault though).

Raul

Raul

>> Being truely wicked here the implication is that for non-LOB apps you can type random SQL in and it will work - hmmmm
>
>Sure. Take EDBManager for example - i can type any SQL into it an it
>just works (does not even have to be sql). Either error or results get
>reported back and in my book this means EDB just works (though there
>might be a problem between chair and keyboard in case of errors - not
>EDB fault though).

I love these silly sort of conversations.

I think you will find that EDBManager knows quite a lot about your databases and tables. That knowledge is generated at run time using information provided in edbmgr.ini and user interaction.

However, since you picked EDBManager here's a little experiment. Open EDBManager. Do not select a session. Click on New. Click into the big white box. Type something (sql or otherwise). Now sit there are try and find an execute button/menu option to click. That only magically appears after you've selected a session. At that point you've told ElevateDB all about your database(s) and tables, and it knows it.

Right off to go and visit the dentist

Roy

This does not work in scripts.  If I have a function defined in DB1 and reference it in an if statement, it errors when it encounters the period.

SCRIPT
BEGIN
 if db2.functionname('test') then
   EXECUTE IMMEDIATE ' do something';
 end if;
END

Roy Lambert wrote:

Ideal

>If I have two databases on the same server, how can I write a query on one database that accesses object on the other database?
>
>For example, a view that unions contents of tableA on DB1 with tableA on DB2.

That depends. If they are defined using the same session then its as simple as prefacing the table name with the database name eg DB1.tableA and DB2.tableA. If they are under different sessions then you have to transport the data from one table and use it to populate a table in the other session.

Roy Lambert

Ideal


Functions & procedures do not cross database boundaries. I do have a request in to Tim to provide session level functions and procedures but I have no idea where in the stack it is (or even if it is in the stack).

Look in the extensions newsgroup for a post with the subject C;loning functions from disk to memory

Roy Lambert