![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 11 to 16 of 16 total |
![]() |
Wed, Feb 4 2015 10:58 AM | Permanent Link |
Raul ![]() | On 2/4/2015 10:35 AM, Roy Lambert wrote:
> Almost right ![]() 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 |
Wed, Feb 4 2015 11:30 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 |
Wed, Feb 4 2015 11:37 AM | Permanent Link |
Raul ![]() | 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 |
Thu, Feb 5 2015 3:25 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 |
Fri, Apr 17 2015 9:51 PM | Permanent Link |
Ideal Software Systems | 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 |
Sat, Apr 18 2015 3:21 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |