Re: Loging and No Log Data Base

From what I hear from Informix it is basically a Informix decision. On 29 Oct 1995 Nils.Myklebust@ccmail.telemax.no wrote: } > CRAIG@CHEMISTRY.CHEM.UTAH.EDU writes: } > } } > } No either way will not work! } > } } > } When I go from the No logging database to the logging data base I get: } > } 569: Cannot reference an external database with logging. } > } } > } When I go from the logging database to the No logging database I get: } > } 568: Cannot reference an external database without logging. } > } } > } Informix I can understand not allowing this for update,insert, delete etc... } > } yet for a general select under ISQL or DBACCESS. What up? } > } Does any know if this will also occur in the 7 online engine? } > } } > } > The situation behaves the same under OnLine 7.11.UC1. (-569/-568 errors) } > } > --Craig (craig@chemistry.utah.edu) } } Could someone perhaps shed some light on this one. Is there some generic } problem with this, or is it Informix that has problems with the way something } is designed. } I can't understand that a simple select from one database to the other could } possibly be a problem. But also updates, inserts, deletes should be possible? } Each database has it's own transaction logs, so why would any of these statements } be more of a problem comeing in over some connection from another database, than } when they arrive from some application? } } We need this kind of access because of problems with very large insert and } update statements in a desition support like situation. We want end users to } be able to select customers from our OLTP database (with transactions) via } selects on a series of tables with different data. They may find up to several } hundred thousand customers, and we need to insert some data (codes/dates) for } each of these to keep track of exactly which customers where selected (and } got some offer or whatever). } With transactions turned on we get all kinds of problems with log size, locking++ } that would easily be avoided if we could simply turn transactions off in the } database we insert the data into. (The transactions aren't needed because any } of the selects could so easily be redone in case of a database crash - and beeing } Informix it hardly ever crashes.) } } There must be a lot of other users in similar situations? } If I could at least get an explanation of the nature of the problem it would } be nice. If it isn't a problem, simply a decision on Informix's part we could } nag them much harder on this. } } Nils.Myklebust@ccmail.telemax.no } NM-data, Dalsbergstien 7, N-0170 Oslo, Norway } My opinions are those of my company } } } }