Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.ms-sqlserver    |    Notorious Rube Goldberg contraption    |    19,505 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 18,761 of 19,505    |
|    =?ISO-8859-1?Q?bj=F6rn_lundin?= to All    |
|    Re: Odbc and client library/drivers    |
|    20 Sep 12 01:58:20    |
      From: b.f.lundin@gmail.com              > How about using views on the server on the same table - then you can        > stick to using "SELECT *" in queries, but you can use different column        > orders on the same table in different views. In MS SQL Server,       > I suppose probably in Oracle as well, you can also INSERT, UPDATE,       > and DELETE on a view.              Yes, however only the client uses views, and the client can not update the DB.              > Also, if your elderly ODBC tool is upset by some modern data types,       > then you could use views so that those columns either don't appear,       > or are CONVERT-ed to something more digestible.              That is no problem. The datatypes we use are present already, but for       XML-type. But this is so different from Oracle's version that       we see no common denominator. So we use varchar to store the xml,       and bring it out from the db, and we parse that string,       either with SAX or with Xpath, within the Ada code.              > For INSERT etc., in such a case, you may be able to define triggers        > on a view that intercept an action that makes excessively simple        > assumptions about the nature of a table where you have actually       > used a view, and, instead, the trigger performs complicated data       > operations that your client program doesn't need to control directly.              Hmm, yes, but all business logis is in Ada.       It will be a nightmare to implement the same logic in both T-sql and pl/sql              we have 1 or 2 trace triggers, that copies a record when it changes to a        trace table. That is bad enough to implement twice.       The reason to have that in trigger code is that we catch       events we might miss otherwise.                     Thanks for the suggestions though       --       Björn Lundin              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca