Oracle trace file question
Hello all I am trying to debug a mysterious sporadic error that a Visual Basic program using ADO is hitting. In reviewing the trace file, we see an odd series of SQL statements. Before performing a 3 table join, a select * from table is issued for each of the tables to be joined. The developer swears ADO isn't doing this. I can't think Oracle would decide to spontaneously do this. These are large tables so if it were really occurring, the communications line would be tied up for a long time, but the developer is able to get subsecond response. Has anyone seen anything like this before? select * from source_reference call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.04 0.12 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.04 0.12 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from account_master call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.05 0.10 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- - total 95 0.05 0.10 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from school_demographics call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.13 0.07 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.13 0.07 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from source_reference sr, account_master am, school_demographics sd where am.lid = 1 and am.lid = 100and am.lid=sr.lid and am.lid=sd.lid order by am.lid asc, sr.source_num asc call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse1 0.03 0.03 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch8 0.03 0.07 7 27 0 100 --- -- -- -- -- -- -- total 10 0.06 0.10 7 27 0 100 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 Rows Row Source Operation --- --- 100 SORT ORDER BY 100 HASH JOIN 100TABLE ACCESS BY INDEX ROWID SCHOOL_DEMOGRAPHICS 101 INDEX RANGE SCAN (object id 3290) 100HASH JOIN 100 TABLE ACCESS BY INDEX ROWID SOURCE_REFERENCE 101 INDEX RANGE SCAN (object id 3294) 100 TABLE ACCESS BY INDEX ROWID ACCOUNT_MASTER 101 INDEX RANGE SCAN (object id 3214) *** -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Oracle trace file question
Okay, I think I answered my own question. If you look at the Fetch line on the select * calls, it is zero. My guess is that ADO is just checking for the existence of each table before it makes the real SQL call. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, September 25, 2002 12:54 PM To: Multiple recipients of list ORACLE-L Hello all I am trying to debug a mysterious sporadic error that a Visual Basic program using ADO is hitting. In reviewing the trace file, we see an odd series of SQL statements. Before performing a 3 table join, a select * from table is issued for each of the tables to be joined. The developer swears ADO isn't doing this. I can't think Oracle would decide to spontaneously do this. These are large tables so if it were really occurring, the communications line would be tied up for a long time, but the developer is able to get subsecond response. Has anyone seen anything like this before? select * from source_reference call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.04 0.12 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.04 0.12 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from account_master call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.05 0.10 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- - total 95 0.05 0.10 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from school_demographics call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.13 0.07 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.13 0.07 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from source_reference sr, account_master am, school_demographics sd where am.lid = 1 and am.lid = 100and am.lid=sr.lid and am.lid=sd.lid order by am.lid asc, sr.source_num asc call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse1 0.03 0.03 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch8 0.03 0.07 7 27 0 100 --- -- -- -- -- -- -- total 10 0.06 0.10 7 27 0 100 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 Rows Row Source Operation --- --- 100 SORT ORDER BY 100 HASH JOIN 100TABLE ACCESS BY INDEX ROWID SCHOOL_DEMOGRAPHICS 101 INDEX RANGE SCAN (object id 3290) 100HASH JOIN 100 TABLE ACCESS BY INDEX ROWID SOURCE_REFERENCE 101 INDEX RANGE SCAN (object id 3294) 100 TABLE ACCESS BY INDEX ROWID ACCOUNT_MASTER 101 INDEX RANGE SCAN (object id 3214) *** -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL
RE: Oracle trace file question
Dennis,
I've seen ADO do some pretty strange stuff under the covers on my project
also. Ny guess is that ADO is sending these sql statements kinda like a
prepare statement, just to see if the query will pass muster - like basic
security checks - does the table exists, etc. My guess is that it just
compiles the sql, but does not fetch any data.
We had something similar with all of our PL/SQL Package call statements. We
traced ADO doing a DBMS_DESCRIBE {package_name} first, getting the parameter
names, then calling the package directly. We got Microsoft in here for
another problem, and he told the developers how to stop ADO from doing that.
It was all an un-documented item, by the way.
If you can, post the question to the Microsoft development team and see what
they say about it. My guess is that they could help you resolve the
problem.
Hope this helps.
Tom Mercadante
Oracle Certified Professional
-Original Message-
Sent: Wednesday, September 25, 2002 1:54 PM
To: Multiple recipients of list ORACLE-L
Hello all
I am trying to debug a mysterious sporadic error that a Visual Basic
program using ADO is hitting. In reviewing the trace file, we see an odd
series of SQL statements. Before performing a 3 table join, a select * from
table is issued for each of the tables to be joined. The developer swears
ADO isn't doing this. I can't think Oracle would decide to spontaneously do
this. These are large tables so if it were really occurring, the
communications line would be tied up for a long time, but the developer is
able to get subsecond response. Has anyone seen anything like this before?
select *
from
source_reference
call count cpuelapsed disk querycurrent
rows
--- -- -- -- -- --
--
Parse 95 0.04 0.12 0 0 0
0
Execute 0 0.00 0.00 0 0 0
0
Fetch0 0.00 0.00 0 0 0
0
--- -- -- -- -- --
--
total 95 0.04 0.12 0 0 0
0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 18
select *
from
account_master
call count cpuelapsed disk querycurrent
rows
--- -- -- -- -- --
--
Parse 95 0.05 0.10 0 0 0
0
Execute 0 0.00 0.00 0 0 0
0
Fetch0 0.00 0.00 0 0 0
0
--- -- -- -- -- --
-
total 95 0.05 0.10 0 0 0
0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 18
select *
from
school_demographics
call count cpuelapsed disk querycurrent
rows
--- -- -- -- -- --
--
Parse 95 0.13 0.07 0 0 0
0
Execute 0 0.00 0.00 0 0 0
0
Fetch0 0.00 0.00 0 0 0
0
--- -- -- -- -- --
--
total 95 0.13 0.07 0 0 0
0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 18
select *
from
source_reference sr, account_master am, school_demographics sd where am.lid
= 1 and am.lid = 100and am.lid=sr.lid and am.lid=sd.lid order by am.lid
asc, sr.source_num asc
call count cpuelapsed disk querycurrent
rows
--- -- -- -- -- --
--
Parse1 0.03 0.03 0 0 0
0
Execute 1 0.00 0.00 0 0 0
0
Fetch8 0.03 0.07 7 27 0
100
--- -- -- -- -- --
--
total 10 0.06 0.10 7 27 0
100
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 18
Rows Row Source Operation
--- ---
100 SORT ORDER BY
100 HASH JOIN
100TABLE ACCESS BY INDEX ROWID SCHOOL_DEMOGRAPHICS
101 INDEX RANGE SCAN (object id 3290)
100HASH JOIN
100 TABLE ACCESS BY INDEX ROWID
RE: Oracle trace file question
That's one way to get a 99.99% buffer cache hit ratio for the statement! -Original Message- Sent: Wednesday, September 25, 2002 11:54 AM To: Multiple recipients of list ORACLE-L Hello all I am trying to debug a mysterious sporadic error that a Visual Basic program using ADO is hitting. In reviewing the trace file, we see an odd series of SQL statements. Before performing a 3 table join, a select * from table is issued for each of the tables to be joined. The developer swears ADO isn't doing this. I can't think Oracle would decide to spontaneously do this. These are large tables so if it were really occurring, the communications line would be tied up for a long time, but the developer is able to get subsecond response. Has anyone seen anything like this before? select * from source_reference call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.04 0.12 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.04 0.12 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from account_master call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.05 0.10 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- - total 95 0.05 0.10 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from school_demographics call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.13 0.07 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.13 0.07 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from source_reference sr, account_master am, school_demographics sd where am.lid = 1 and am.lid = 100and am.lid=sr.lid and am.lid=sd.lid order by am.lid asc, sr.source_num asc call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse1 0.03 0.03 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch8 0.03 0.07 7 27 0 100 --- -- -- -- -- -- -- total 10 0.06 0.10 7 27 0 100 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 Rows Row Source Operation --- --- 100 SORT ORDER BY 100 HASH JOIN 100TABLE ACCESS BY INDEX ROWID SCHOOL_DEMOGRAPHICS 101 INDEX RANGE SCAN (object id 3290) 100HASH JOIN 100 TABLE ACCESS BY INDEX ROWID SOURCE_REFERENCE 101 INDEX RANGE SCAN (object id 3294) 100 TABLE ACCESS BY INDEX ROWID ACCOUNT_MASTER 101 INDEX RANGE SCAN (object id 3214) *** -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the
RE: Oracle trace file question
Boy, I go to a new job and I don't have any of my old notebooks. I remember something like this from the past from a third-party app. The first three queries would just be verifying the existance of the object. Can't remember if it was via a SELECT * (I don't think so) or some other similar query. Your app isn't really doing a SELECT * since the fetch.count and fetch.rows are both 0, so I bet it is also just object verification. Henry -Original Message- WILLIAMS Sent: Wednesday, September 25, 2002 1:54 PM To: Multiple recipients of list ORACLE-L Hello all I am trying to debug a mysterious sporadic error that a Visual Basic program using ADO is hitting. In reviewing the trace file, we see an odd series of SQL statements. Before performing a 3 table join, a select * from table is issued for each of the tables to be joined. The developer swears ADO isn't doing this. I can't think Oracle would decide to spontaneously do this. These are large tables so if it were really occurring, the communications line would be tied up for a long time, but the developer is able to get subsecond response. Has anyone seen anything like this before? select * from source_reference call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.04 0.12 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.04 0.12 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from account_master call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.05 0.10 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- - total 95 0.05 0.10 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from school_demographics call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.13 0.07 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.13 0.07 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from source_reference sr, account_master am, school_demographics sd where am.lid = 1 and am.lid = 100and am.lid=sr.lid and am.lid=sd.lid order by am.lid asc, sr.source_num asc call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse1 0.03 0.03 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch8 0.03 0.07 7 27 0 100 --- -- -- -- -- -- -- total 10 0.06 0.10 7 27 0 100 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 Rows Row Source Operation --- --- 100 SORT ORDER BY 100 HASH JOIN 100TABLE ACCESS BY INDEX ROWID SCHOOL_DEMOGRAPHICS 101 INDEX RANGE SCAN (object id 3290) 100HASH JOIN 100 TABLE ACCESS BY INDEX ROWID SOURCE_REFERENCE 101 INDEX RANGE SCAN (object id 3294) 100 TABLE ACCESS BY INDEX ROWID ACCOUNT_MASTER 101 INDEX RANGE SCAN (object id 3214) *** -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting
RE: Oracle trace file question
Dennis, Ask Anjo about his Magic utility. Using that utility one has to set an environment variable on the client which would tune and avoid extra parse sql before they are sent to Oracle. Infact Cary mentions about this in his emails. btw we use delphi 3rd party ODAC component instead of ADO/BDE which avoids extra parse. -Original Message- From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 10:54 AM To: Multiple recipients of list ORACLE-L Subject: Oracle trace file question Hello all I am trying to debug a mysterious sporadic error that a Visual Basic program using ADO is hitting. In reviewing the trace file, we see an odd series of SQL statements. Before performing a 3 table join, a select * from table is issued for each of the tables to be joined. The developer swears ADO isn't doing this. I can't think Oracle would decide to spontaneously do this. These are large tables so if it were really occurring, the communications line would be tied up for a long time, but the developer is able to get subsecond response. Has anyone seen anything like this before? ** ** select * from source_reference call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.04 0.12 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.04 0.12 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 ** ** select * from account_master call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.05 0.10 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- - total 95 0.05 0.10 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 ** ** select * from school_demographics call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.13 0.07 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.13 0.07 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 ** ** select * from source_reference sr, account_master am, school_demographics sd where am.lid = 1 and am.lid = 100and am.lid=sr.lid and am.lid=sd.lid order by am.lid asc, sr.source_num asc call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse1 0.03 0.03 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch8 0.03 0.07 7 27 0 100 --- -- -- -- -- -- -- total 10 0.06 0.10 7 27 0 100 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 Rows Row Source Operation --- --- 100 SORT ORDER BY 100 HASH JOIN 100TABLE ACCESS BY INDEX ROWID SCHOOL_DEMOGRAPHICS 101 INDEX RANGE SCAN (object id 3290) 100HASH JOIN 100 TABLE ACCESS BY INDEX ROWID SOURCE_REFERENCE 101 INDEX RANGE SCAN (object id 3294) 100 TABLE ACCESS BY INDEX ROWID ACCOUNT_MASTER 101 INDEX RANGE SCAN (object id 3214) ** ** *** -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS
Re: Oracle trace file question
It's ODBC, I think. The MS ODBC driver (are they using ODBC? If so, is it an MS driver or an Oracle driver?) tends to do SELECTs like this in lieu of a DESCRIBE. They don't fetch from the cursors; they just read the select-column information returned in order to perform a crude DESCRIBE of the table... - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, September 25, 2002 11:53 AM Hello all I am trying to debug a mysterious sporadic error that a Visual Basic program using ADO is hitting. In reviewing the trace file, we see an odd series of SQL statements. Before performing a 3 table join, a select * from table is issued for each of the tables to be joined. The developer swears ADO isn't doing this. I can't think Oracle would decide to spontaneously do this. These are large tables so if it were really occurring, the communications line would be tied up for a long time, but the developer is able to get subsecond response. Has anyone seen anything like this before? select * from source_reference call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.04 0.12 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.04 0.12 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from account_master call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.05 0.10 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- - total 95 0.05 0.10 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from school_demographics call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse 95 0.13 0.07 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch0 0.00 0.00 0 0 0 0 --- -- -- -- -- -- -- total 95 0.13 0.07 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 select * from source_reference sr, account_master am, school_demographics sd where am.lid = 1 and am.lid = 100and am.lid=sr.lid and am.lid=sd.lid order by am.lid asc, sr.source_num asc call count cpuelapsed disk querycurrent rows --- -- -- -- -- -- -- Parse1 0.03 0.03 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch8 0.03 0.07 7 27 0 100 --- -- -- -- -- -- -- total 10 0.06 0.10 7 27 0 100 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 18 Rows Row Source Operation --- --- 100 SORT ORDER BY 100 HASH JOIN 100TABLE ACCESS BY INDEX ROWID SCHOOL_DEMOGRAPHICS 101 INDEX RANGE SCAN (object id 3290) 100HASH JOIN 100 TABLE ACCESS BY INDEX ROWID SOURCE_REFERENCE 101 INDEX RANGE SCAN (object id 3294) 100 TABLE ACCESS BY INDEX ROWID ACCOUNT_MASTER 101 INDEX RANGE SCAN (object id 3214) *** -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting
