Tom, I've been on holiday for a few days but I picked up on what you wrote last week: > Sometimes it would work, other times it would bum out. > Sometimes I would get an error message and sometimes not. > The error message was not specific enough for me to trace > the source of the bug but I cognited after a recent post > that I should maybe set the variables required by views > (even though I have taken Bill's advice and all variables > in view definitions are enclosed in parenthesis). > I did that and it did not solve the problem (interestingly > enough the CHOOSE took FAR longer to display by setting > the var first) BUT it did give me a different error > message - I had a permanent view based on a temporary > table that was not defined. I deleted the view and voila! > No more crashes! I'm not sure if you are referring to what I wrote a few weeks ago in response to Bill Downall's comments about problems: > Very interesting, Bill, so might we deduce from your > theory that by creating/defining in either the rbase.dat > or .cfg files, _before_ connecting to the database, _all_ > the _embedded_ variables that are held anywhere in that > database _structure_ that some or all of the weird and > unexplained problems might disappear? If so, it is a > simple resolution and it does seem reasonable that R:Base > might like to have defined any variables that it _might_ > need to use or know about. I was a little surprised that nobody commented on this. Your experience looks as if it might not be as straight forward as it seems. However, I have a db with a report based on a temporary table which, naturally, has to be created _before_ I can amend the report - and how many times do I forget that? You got it, nearly every! Your permanent view/temporary table combination is - with hindsight - perhaps an obvious "no-no" which tends to make me think there is some value in ensuring everything is made available to R:Base before or at the time a database is connected to. (This is not a criticism - just a case of a workman getting ready all the tools needed for a job before starting work.) As for views in general, I am rapidly coming to the conclusion that the best view is a temporary one - simply because they appear to be so much more easily configurable at the time of requesting data. Does anybody have any views (sorry, no pun intended) on whether it is better to create/define everything that might be needed before connecting or immediately after connecting to a database? It's not too hard to do and R:Base even provides a standard file to do so in an application. Is there too much of a memory overhead if large temporary views/tables are created and held by R:Base? It seems to me that there is a nugget of something important here that might be valuable to a number of people on this list if a definitive methodology can be produced. It is so often the simple little self-created problems that cause the biggest headaches and getting rid of a few of them would be a huge advantage. Regards, Alastair
