Ted: After all the help from everyone and looking at the code what you
say makes sense. Something is triggering the stored procedure in the
database because records are getting added without a user entering them
and the invoice numbers are in perfect sequence. Sometimes it's one
record, sometimes two and sometimes up to 20 appended in a row. One
thing is certain. Records are being added without user intention.
Also, every valid record is accounted for.
This is a web connection application which I neglected to mention, which
may enter into the formula.
Nothing changed in June except they claim that the first duplicated
order had "Denmark" and gibberish in it. I am sure, however, that there
are towns named Denmark that they deliver to.
As always, thank you for your help.
This is a good one! ;^)
Jeff
---------------
Jeff Johnson
[email protected]
(623) 582-0323
www.san-dc.com
www.arelationshipmanager.com
On 02/22/2013 07:14 PM, Ted Roche wrote:
Jeff:
The concern that comes to mind is that *something* is intervening between
the APPEND and the SCATTER commands, and the record pointer of the
underlying table is getting moved, so the SCATTER is overwriting another
record. That could be all sorts of bad.
Something like a grid or a browse or a lookup query getting refreshed on
the table in the question could be wiggling the record pointer at the
critical moment, even if "no code is running" while the method is
processing. This is yet another reason why INSERT and a single pass at the
table is much better than APPEND and SCATTER commands.
You'll want to audit the data against other records the client may have to
determine if all of the records they should have are actually present in
the file.
Do you have the code in source control? It's worth poking around to see if
some change was put into place around the period the new data problems
started appearing. It's also a good idea to check to make sure the client
has some good backups, as you'll likely want to do some day-to-day compares.
On Fri, Feb 22, 2013 at 7:45 PM, Jeff Johnson <[email protected]> wrote:
Frank: Thanks. I do not see any way of reverting an added record if the
user wants to cancel. A new record is always created and the there
doesn't seem to be any form or fashion of cancel. I will investigate it
though.
Thanks,
Jeff
---------------
Jeff Johnson
[email protected]
(623) 582-0323
www.san-dc.com
www.arelationshipmanager.com
On 02/22/2013 04:28 PM, Frank Cazabon wrote:
Jeff, the only way I can think this is happening is if some combination
of factors is causing the APPEND command to run (unless you've got INSERT
commands around too) without the user realising this.
Does this application use a DBC? Maybe you could create a database event
that logs the data to a text file whenever a new record is added and track
any other data that might help you track it down. Maybe user or machine
name, date and time and if possible what program and line of code it was
called on.
Frank.
Frank Cazabon
On 22/02/2013 05:23 PM, Jeff Johnson wrote:
I also found out that 40 percent of their orders are phantom orders!
Over the last nine months the phantom orders are 50% of the orders on the
highest volume day and 18% on the lowest volume day. Sure points to volume
but why 40% overall! And most of them are in large blocks of 20 to 60
orders in a row.
When appending records there is a stored procedure called newid('order')
that is set to the default value for the invoice number. Most of their
records are copied from a previous invoice. scatter invoice to copy,
append blank (which generates the new invoice number using the stored
procedure) gather some fields. After editing the save does an sql
update/set.
It was working fine until June of last year. They think they were
hacked but what could someone hack to cause this problem?
Thanks again for all your help.
Jeff
---------------
Jeff Johnson
[email protected]
(623) 582-0323
www.san-dc.com
www.arelationshipmanager.com
On 02/22/2013 02:03 PM, Kurt wrote:
Well - I guess you slashed One Phantom off your List! :-)
As for a Corrupt EXE - I doubt it. How could it be corrupt - such that
the
system Works - but, adds strange records. I suspect a truly corrupt EXE
would just Crash or Not work at all! I think the culprit is elsewhere...
-K-
-----Original Message-----
From: ProfoxTech
[mailto:profoxtech-bounces@**leafe.com<[email protected]>]
On Behalf Of Jeff
Johnson
Sent: Friday, February 22, 2013 2:31 PM
To: [email protected]
Subject: Re: Weird Problem Adding Records to a Table
Is there any chance at all that the executable could be corrupt? I
don't know if I mentioned it but on some days there could be 60 or 70
phantom records right in a row.
Update. The slash is merely a coincidence based on my test. The slash
has nothing to do with phantom records.
Jeff
---------------
Jeff Johnson
[email protected]
(623) 582-0323
www.san-dc.com
www.arelationshipmanager.com
On 02/22/2013 12:23 PM, MB Software Solutions, LLC wrote:
On 02/22/2013 07:33 AM, Kurt wrote:
My suggestion - KILL that Append/Gather - and replace that code with
an SQL
Insert! Its what I have done in the past in some problem areas of
systems -
and its done Wonders!!!
INSERT INTO MyTable FROM NAME if you've got objects to insert;
otherwise direct INSERT INTO MyTable (fields) VALUES (values) like he
said should fix it. I recall that from VFP5 days in late 90s.
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
