>>> Now do it differently <<< I meant to write."Now I do it differently." I did not mean to tell you what to do, rather how I do it :-) Javier, Javier Valencia, PE 913-829-0888 Office 913-915-3137 Cell 913-649-2904 Fax Visit us at www.vtgonline.com <http://www.vtgonline.com/> _____
From: [email protected] [mailto:[email protected]] On Behalf Of Javier Valencia Sent: Wednesday, June 22, 2011 2:25 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Microrim variables and FILES setting Mike, Your symptoms are pretty much what I observed. Now do it differently. I project the entire SATTACHEd table or a portion with the data I need, after which I am working strictly with R:Base tables.; it seems to work like a charm and the temporary tables are very fast to boot. Javier, Javier Valencia, PE 913-829-0888 Office 913-915-3137 Cell 913-649-2904 Fax Visit us at www.vtgonline.com <http://www.vtgonline.com/> _____ From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, June 22, 2011 1:57 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Microrim variables and FILES setting Javier: Recently I have been PROJECTing an empty table from the SATTACHed table and then doing the INSERT INTO command. I split the steps apart to be as deliberate as possible in trying to trap for the offending event. The DBA suggested I look for incompatible data types or bad data. Neither of these has revealed anything. What makes this problem more frustrating is that as soon as I restart R:BASE and re-run the offending command file it runs without a hitch and may do so for several more iterations. Thanks for the input. Mike 740-829-4340 Office 740-502-1659 Cell From: "Javier Valencia" <[email protected]> To: [email protected] (RBASE-L Mailing List) Date: 06/22/2011 02:33 PM Subject: [RBASE-L] - RE: Microrim variables and FILES setting Sent by: [email protected] _____ Mike, I had similar issues (albeit on 7.5) when inserting/appending data from an SATTACHEd table to a local table. The solution was to project a temporary table from the SATTACHEd table and then do the insert/append from that table. I am currently using that technique (using 9.1) to extract data from SQL database and I have not had any problems. Javier, Javier Valencia, PE 913-829-0888 Office 913-915-3137 Cell 913-649-2904 Fax Visit us at <http://www.vtgonline.com/> www.vtgonline.com _____ From: [email protected] [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, June 22, 2011 12:56 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Microrim variables and FILES setting Good afternoon: I'd like to hear comments from anyone who might be using the MICRORIM_F2MAXBLK and MICRORIM_F3MAXBLK variables and the FILES setting. I'm using Turbo V-8 on Windows XP Pro w/SP3 on a machine with 4GB of RAM. My reason for asking is that I am experiencing sporadic crashes of the RBG8.EXE program while extracting data from a SQL Server database via an ODBC connection. The best I can determine is that the crashes are occurring at the moment that I am inserting the last record of the selection into a local R:BASE table. The crashes are of the sort where I get the nice little box apologizing for the crash and do you want to send the information to Microsoft. Until I clear this box the database is locked and I restart R:BASE. A DBA consultant suggested that I bump up the files and buffers on my system. The crashes are sporadic and impossible to trap for as far as I know since it kills R:BASE. Thanks for any suggestions. Mike Ramsour c/o AK Steel Coshocton Works Confidentiality Notice This message is intended exclusively for the individual or entity to which it is addressed and may contain privileged, proprietary, or otherwise private information. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. Confidentiality Notice This message is intended exclusively for the individual or entity to which it is addressed and may contain privileged, proprietary, or otherwise private information. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
