This seems really weird but I can duplicate it every time. Anybody have a solution?
User starts a search from the "original" web page which opens Page 1 to run the search:
- Page 1 gets a temp file name using Session.full_temp_tbl_name = Request.GetRequestTempFileName( ".dbf" )
- Page 1 creates that file, opens that file, adds records to it, and closes the table. (Records come from filtering a much, much larger table. The initial filter can take a LONG time - over one minute in some cases. That's why I want to dump the results to a temp table - so future sorting, different views, and possibly exporting to an Excel or CSV file will be quick.)
- Page 1 then re-opens that table and creates a crlf() list based on that data. (The crlf() list is used to create an HTML table. I.e., it's a list of rows for a table.)
- The user clicks on a button to jump to "Page 2" which might either export the data or display the same data with different fields.
- Page 2 says that temp table doesn't exist. ERROR!
Now the weird part:
- Click the back button a couple times to get back to the "original" page and start the exact same search again.
- Page 1 works as described above. (I even put some messages in to see if the table was being created or already existed and it is being created "again".)
- The user clicks on a button to jump to "Page 2" which might either export the data or display the same data with different fields.
- Page 2 WORKS PEFECTLY.
At this point, all subsequent attempts to read the temporary file work perfectly as long as the session is still valid. Start any new session and the same issue occurs the first time through.
This happens in v11 or v12 WAS.
More info:
The temporary file - once it works - is stored in my Temp folder. But after the first time through, only the .ddd, .ddm, and .ddx files are there. After the second time through the .dbf file appears. This matches the fact that the second page can't see it the first time through but can every time after that.
If you don't mind downloading a 20 meg video, you can see it in action here along with views of the folders where the temp files are/should be:
www.aimsdc.net/temp_file_not_there.wmv (not sure how long I will leave it there but at least for the next couple weeks)
For now, the only solution I can come up with is to manually create a "temporary" file in the data folder (or some other folder) and include the date in the file name so I can have the login page delete any file that is more than 1 day old. The down side to that is that we could easily have over 100 users in one day plus some of them could log on multiple times per day. At 4 files per session (the .dbf, .ddd, .ddm, and .ddx for every table), that would be over 400 files per day even if they only log on once. With multiple logins we could end up with over 1000 temp files!
By the way, these are hard coded web pages because the customer wants to see lists that could be as much as 1000 lines long displayed on one page and web components are, or at least were, limited to 100 lines per page. There are no web components in these pages and they are not "published". The vast majority of what's on these pages is xbasic code - the search definitions/filters can be rather complex - and I just copy them to the web folder and they work.
I also tried moving the temp file to the session folder using Session.SaveDataAsFile() but couldn't make that work at all because I couldn't access it in xbasic once I moved it.
In versions prior to v11 this was not an issue because you could easily work with files in the session folder. And when the session died, the temp files disappeared right along with the session folder.
And, in case you are wondering, no, there is no good way to identify specific users at this time. The only way right now would be to compare both the user name and password. But even doing that would only allow me to solve the problem of multiple logins by the same person. And that would mean creating a unique file or folder name for each person based on their name and password - which probably wouldn't be a good idea. That doesn't sound very secure to me and it could get real messy real fast.
User starts a search from the "original" web page which opens Page 1 to run the search:
- Page 1 gets a temp file name using Session.full_temp_tbl_name = Request.GetRequestTempFileName( ".dbf" )
- Page 1 creates that file, opens that file, adds records to it, and closes the table. (Records come from filtering a much, much larger table. The initial filter can take a LONG time - over one minute in some cases. That's why I want to dump the results to a temp table - so future sorting, different views, and possibly exporting to an Excel or CSV file will be quick.)
- Page 1 then re-opens that table and creates a crlf() list based on that data. (The crlf() list is used to create an HTML table. I.e., it's a list of rows for a table.)
- The user clicks on a button to jump to "Page 2" which might either export the data or display the same data with different fields.
- Page 2 says that temp table doesn't exist. ERROR!
Now the weird part:
- Click the back button a couple times to get back to the "original" page and start the exact same search again.
- Page 1 works as described above. (I even put some messages in to see if the table was being created or already existed and it is being created "again".)
- The user clicks on a button to jump to "Page 2" which might either export the data or display the same data with different fields.
- Page 2 WORKS PEFECTLY.
At this point, all subsequent attempts to read the temporary file work perfectly as long as the session is still valid. Start any new session and the same issue occurs the first time through.
This happens in v11 or v12 WAS.
More info:
The temporary file - once it works - is stored in my Temp folder. But after the first time through, only the .ddd, .ddm, and .ddx files are there. After the second time through the .dbf file appears. This matches the fact that the second page can't see it the first time through but can every time after that.
If you don't mind downloading a 20 meg video, you can see it in action here along with views of the folders where the temp files are/should be:
www.aimsdc.net/temp_file_not_there.wmv (not sure how long I will leave it there but at least for the next couple weeks)
For now, the only solution I can come up with is to manually create a "temporary" file in the data folder (or some other folder) and include the date in the file name so I can have the login page delete any file that is more than 1 day old. The down side to that is that we could easily have over 100 users in one day plus some of them could log on multiple times per day. At 4 files per session (the .dbf, .ddd, .ddm, and .ddx for every table), that would be over 400 files per day even if they only log on once. With multiple logins we could end up with over 1000 temp files!
By the way, these are hard coded web pages because the customer wants to see lists that could be as much as 1000 lines long displayed on one page and web components are, or at least were, limited to 100 lines per page. There are no web components in these pages and they are not "published". The vast majority of what's on these pages is xbasic code - the search definitions/filters can be rather complex - and I just copy them to the web folder and they work.
I also tried moving the temp file to the session folder using Session.SaveDataAsFile() but couldn't make that work at all because I couldn't access it in xbasic once I moved it.
In versions prior to v11 this was not an issue because you could easily work with files in the session folder. And when the session died, the temp files disappeared right along with the session folder.
And, in case you are wondering, no, there is no good way to identify specific users at this time. The only way right now would be to compare both the user name and password. But even doing that would only allow me to solve the problem of multiple logins by the same person. And that would mean creating a unique file or folder name for each person based on their name and password - which probably wouldn't be a good idea. That doesn't sound very secure to me and it could get real messy real fast.
Comment