Sukesh, I agree that you should always define explicitly your select list, for many reasons speed being the main one.
I just remembered something else that may be impacting the compile issue. I suspect not but just in case. We had problems where our compile was messing up. It turned out to be that we had the same application on the same machine in two separate namespaces. Modifications had been made to some of the classes in one namespace but not the other. Then the code in each namespace was compiled at the same time. The compiling would leak from one to the other and mess up one of the compile sometimes both. to fix it we had to create a separate temporary database for each namespace. Configuration Manager->Namespaces->#namespaceName#->Default Databases->Temporary Storage by default they all point to CacheTemp database. I doubt this is the problem but one to eliminate. Jack Stevenson Senior Product Development Manager Mtivity London UK +44 (0) 207 801 6211 "Sukesh Hoogan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Max & Jack > > Elsewhere in the thread mentioned - that there were problems on one machine > and no problems on another machine. > > I must add that none of the queries in my db schema are of the type SELECT * > FROM ... > All select queries state the properties explicitly - .SELECT prop1, > prop2,....... FROM > The latter is more efficient and faster and the recommended way, even if one > needs to select all the properties.. > > -- > Sukesh Hoogan > e-Linear Enterprise Solutions > Bombay, India > http//personal.vsnl.com/sukesh_hoogan (updated : June12 , 2004) > > > > Jack Stevenson <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Max, > > > > I am late to this thread buy I may have something that helps. > > > > We faced a problem like this a while ago, similar, our structure grew > large > > with lots of dependencies, and some circular references and very similar > > symptoms as you in general. > > > > We seem to have solved in now. > > > > We compile using the command > > > > d $System.OBJ.CompileAll("f") > > > > It took a lot of effort to narrow down the problem. > > > > One of the most annoying to find was using 'Select *' in queries. Apart > > from it being bad form anyway, it seems to cause problems in the compile, > > and doesn't report a proper error. > > > > Apart from that we just went looking for all our errors and removed a lot > of > > old 'unused/unneeded' classes and dependencies. > > > > It was an incremental process finding one error fixing it then compiling > all > > again then finding the next error and repeating until the compile was > clean. > > > > We still have one error reporting at the end, unassociated to the class > that > > has the problem, but it does not seen to be causing a problem (that we can > > find). > > > > I recommend turning logging on when doing the compile in Terminal so that > > you can go back and look over the compile output and see what the errors > > are. > > > > Once there is an error even small that class does not compile properly > then > > anything that is dependant on it will not compile, expanding > exponentially. > > > > We now as part of our process run a full compile after all new development > > to ensure that no unexpected compile errors have been introduced. It is > > easier to fix them as they are produced rather than going back later and > > finding them all. > > > > I hope this helps, and good luck, it is a frustrating problem. > > > > Jack Stevenson > > Senior Product Development Manager > > Mtivity > > London UK > > +44 (0) 207 801 6211 > > > > > > "Max Sebastiani" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > Hello again! > > > > > > > > > > > I would suggest you use the following format for $system.OBJ.Compile: > > > > > > > > Do $system.OBJ.Compile( class, "bruy" ) > > > > > > > > > > ,,we have been using "r-bkvu" until now, and also tried a lot of > > > combinations, no results. > > > > > > > From the documentation (Do $system.OBJ.ShowFlags()), "b" will compile > > > > subclasses; "r" compiles all classes that are dependency predecessors; > > > > "u" avoids compiling up-to-date classes (albeit as you say sometimes > you > > > > need "f", the opposite); and "y" finds dependencies within SQL (and I > > > > don't remember seeing that one before!) > > > > > > > > > > The "y" is something new, I really need it! Our problems are 99% with > SQL. > > > Although I just tried, no visible changes to the results (with 5.07). > :-( > > > > > > I'm thinking about moving all our queries apart, into different classes > > > which somehow will be compiled later. But it's a disaster, we have about > > 150 > > > of them... > > > Also, having good tests is difficult, we always have to start with an > > empty > > > database, or the tests will be influenced by what we have compiled > before. > > > > > > I understand that it's a complicated issue to solve for ISC, but a > > compiler > > > which doesn't know how to compile its classes is a big limitation for OO > > > enterprise projects. We need to scale to about 1000 classes by the end > of > > > the year, and now I'm seriously starting to worry about it. > > > > > > Max > > > > > > > > > > > > > >
