Re: Date funny in SQL*Forms 3.0
Date: Wed, 19 Jan 1994 13:15:15 GMT
Message-ID: <CJvotF.M1o_at_melpar.esys.com>
In article <2hhbfr$f38_at_nnrp.ucs.ubc.ca>, mirek_at_unixg.ubc.ca (Miroslaw Piaseczny) writes:
> In article <17JAN199415050775_at_erich.triumf.ca>,
> Peter A. Grant <grant_at_erich.triumf.ca> wrote:
> >
> >A strange bug has crept into one of my forms which I don't really understand.
> >A field is defined to be a DATE - a DATETIME in Forms. Almost always
> >repeatable, the day, year, and time are all updatable, but if you change the
> >month, it magically changes back to what it was when you leave the field or
> >commit the record.
> >
> >I ran it in debug mode and there weren't any triggers reported as being
> >fired. Pretty odd. Any bright ideas?
> >
>
> It could be a problem with usage of the mask format. Especially, make sure you
> don't specify 'MM' for the minutes part of the format.
>
> Mirek Piaseczny
> mirek_at_unixg.ubc.ca
>
>
We are experiencing the same thing. Using the DOS SQLnet driver for either PCnfs version 4.0 or FTP Inc version 2.x we see very long waits for queries that run like blazes on the UNIX box directly or even using SQLnet UNIX to UNIX. This is a simple query that returns about 1.5 MB worth of data in a report.
I monitored the query's background process on the server and the query runs just as fast locally as it does over the net. However, this is only to do the query, now we begin to differ. The local query (or the one using UNIX to UNIX SQLnet) now outputs the results of the query. This runs fine, but the query from the DOS system spends a TON of time in a SOCKET wait state. I used TCPDUMP to analyze the network traffic and noticed a LONG delay in between the time the UNIX system sends a packet and the DOS system sends back an acknowlodgement. This varies for different speed DOS systems (almost at the same difference as the MIP rating for that processor) however, the delays range from 0.5 seconds to 2.0 seconds. Each packet that the server sends to the DOS system is 512 bytes, so I can see why it takes so long to get the job done. We are currently waiting for a new release of the DOS based SQLnet driver and would like to know from others that experience this same problem.
The problem is not triggers, database locking, or anything else as this is just a query of a large database. As I stated the query runs fine until the part where the results are sent back, then we sit and wait, and wait. Sort of like waiting for some of the fixes we need from Oracle.
barry suskind
-- ----- Barry A. Suskind, Information Services, E-Systems Melpar Division ----- ---------------- 7700 Arlington Blvd, Falls Church, VA 22046 ---------------- ---- Internet: suskind_at_melpar.esys.com ----------- Ma Bell: 703-560-5000 ---- ------------------------------------------------------------------------------ "After all, if it weren't for change, your job would largely consist of making sure the corporate abacus rods were adequately greased." -------- John CleeseReceived on Wed Jan 19 1994 - 14:15:15 CET