Robert Freeman wrote:
Usually I (as a customer) require few things in good book - some value added over documentation.In this new book, I'm considering biasing my coverage to OEM for a few reasons: 1. OEM is less complex to use. 2. Adding coverage for both will take up many more pages. When you are writing a book you are limited to a page count range, so depth is limited based on this too. 3. The Code route, in and of itself, can be complex. I'm not sure if it's worth the extra time to add the code in some cases just because of this complexity. I'm wondering if anyone who has used these features or suspect they will use them in the future has a preference. In some cases, if page count allows, I'll do both. In some cases I need to select either/or due to page count considerations. In the past, I've been very heavily code oriented and really relegated OEM to the background, but now I'm thinking of moving in the other direction. Thoughts?? RF
It sometimes means exactly an explaination of complex things in clear way.And certainly not description of "every" page of OEM - I do not read them for example, what would be really interested are procedures to diagnose SQL (using OEM), to set Data Guard working, etc - more in a way of O'Reilly "... Cookbooks".
just my 3 cents, hope book will be good :-) Remigiusz -- --------------------------------------------------------------------- Remigiusz Sokolowski <rems@xxxxxxxx> WP/PTI/DIP/ZAB (+04858) 52 15 770 MySQL v04.x,05.x; Oracle v10.x Zastrzezenie:Niniejsza wiadomosc stanowi jedynie wyraz prywatnych pogladow autora i nie jest w zadnym wypadku zwiazana ze stanowiskiem przedsiebiorstwa Wirtualna Polska S.A.
---------------------------------------------------------------------WIRTUALNA POLSKA SA, ul. Traugutta 115c, 80-226 Gdansk; NIP: 957-07-51-216; Sad Rejonowy Gdansk-Polnoc KRS 0000068548, kapital zakladowy 62.880.024 zlotych (w calosci wplacony)
-- //www.freelists.org/webpage/oracle-l