numero = 17658
interpreted = N
texte = There's nothing wrong with your WebDNA code that creates the popup, but have you tried using method=POST to see if that makes any difference? I never use method=GET in my forms anymore, so possibly that's the problem, although I doubt it. But it's one more thing to check, just to be sure ...If you're using the plugin, you may be using too small a ThreadMem setting in the WebCatalog Prefs file. The reason I'm thinking of this possibility is that the search that creates your popup is not selecting an exact matching record like the one on the following page does -- it's selecting all the records greater that 03/01/98 -- which results in a search that takes far more resources than an exact match search. And putting accdatesumm=T into that popup search string adds even more to the WebCat resource requirements. Of course, accdatesumm=T is a required parameter for what you're trying to do, so if you're using the plugin with the default 48 setting for the ThreadMem preference, or even if you've increased it to 72, try bumping that value up to 96 or 128 and see if that makes any difference. MAybe the thread that's processing this popup search just needs a lot more RAM than you might expect.I was told a while back that the order of the search parameters doesn't make any difference, but that's not true in some situations either, so you might want to try using the same parameter order in the popup code that you're using for the search on the next page. I doubt this will make any difference, since these search parameters don't seem to be ones that would have to be placed in any particular order in order to work properly ... but maybe it actually will make a difference, who knows?Basically my feeling is this:Although it's a hassle to change your existing WebDNA code (and database date values) from a common date format to storing dates as the number of days since 00/00/0000, I'm convinced that right now, making this changeover is the best way to insure that everything works properly when dealing with WebCat dates. Searches will definitely be faster because there are no text-to-date and date-to-text conversions to make, and all your date searches will require less in the way of WebCat resources as well, thus helping to prevent potential resource problems like the one you may be seeing here.I can tell you one thing for sure, after having switched over to storing dates as the number of days since 00/00/0000, I'm finally able to deal with dates reliably and effectively -- without ANY of the date problems I've experienced in the past -- so I'm sticking with what works for me. Besides, it's a permanent long-term solution no matter what changes PCS makes to its underlying date processing code, because my solution allows all date comparisons to be done as text -- which just happens to be the fastest and the most reliable comparison method available in WebCatalog and Typhoon ... :)Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net >This is what creates the popup menu (and crashes WebSTAR): > > > >I removed the &accdatetype=date and it works fine. The weird thing is, on the >next page I have: > >[search db=offshorelog.db&eqaccdatedata=[popup]&accdatetype=date&deaccdatesort=1&deacctimesort=2&max=500] > >and that works fine. That's why I'm thinking that the bug is in the creation >of a popup menu on the fly from a search involving dates. > >In any case, your suggestion is a good one, as usual, and I think I've already >figured out a way to do that. > >Kenneth Grome wrote: >> >> >> [accdate] should not interfere with [date] as far as the search routines are concerned. This problem was fixed in 2.0 quite a while ago. How big is your database? Try taking out the summ=T - depending on the size of the database, this could require additional RAM. >> >> >I discovered that the same syntax works fine when not enclosed in the