"unique" field rule problem.

[Robert Bowman]

I�m in process of converting a A5v3 database to A5v5. The database is a set containing several tables. The �Header� and �To_buy� tables contain the most critical information. Header has a field based on the requisition number (Req_numb), which must be unique. The forms used have an embedded browse linked by the requisition number field. I didn�t notice this before when I was beta testing � but then I was the only one making entries and it was not apparent. Now I�m at the point where more than one individual is making entries and the risk of duplicate records has occurred several times.

The Header has 3444 records and the To_buy has 6679 records. I don�t know if the problem is with the number of records in the database or if something else is going on.

When I enter a duplicate Req_numb to the header and save -- the records in the To_buy table with that Req_numb are aligned with the current Req_numb.

I�ve ran the re-evaluate field rules option, both in the system record number order and on an index based on Req_numb with a known duplicate requisition number. In the record number order the status indicated 3444 records processed and 3442 records marked. Running in the Req_numb order � the status indicated the same results. When looking at the table I don�t see that any of the records have been marked. (I�m assuming that the marked records will have the block in the extreme left marked as in the v3 deleted record.). I also ran a filter query (.t. and Marked()) which yielded no records.

I also have A5v4. This morning I transferred the A5v3 files into a test directory and experienced the same problem.

The criticality is that the database tracks fund expenditures. The database also tracks sources and delivery information.

Please help.

Thank you,


R. Bowman

[russ Boehle]

RE:

Try Operations, mark duplicate records then do a query and show only marked records.

Hope this helps

Russ

[whanigsberg]

RE:

Is the application networked? If so where is the data? May I presume that referential integrity enabled.

Bill

[John Lemisch]

RE:

I have seen this type of problem and just wanted to link the message.

[Robert Bowman]

RE:

I did my initial change from v3 to v5 on my computer and local server using v4.5. Upon receiving v5 I opened the server version with the v5.

This morning I tested v4.5 "unique" field rule only on my computer.

I have referential integrity "cascade changes/deletes" in my set. Is there another area that I need to address referential integrity?

Thanks


Bob

[Robert Bowman]

RE:

For Russ

I ran the operations as suggested. At least now I know what a marked record looks like for sure.

Thanks

Bob

[whanigsberg]

RE:

Robert,
Which table has the duplicate records?
Bill

[Robert Bowman]

RE:

It's in the header.dbf. I've been using v3 to run this application since 1996 -- without a problem.

Thanks

Bob

[whanigsberg]

RE:

Bob,

It may be time to post a sample.

Meanwhile, what happens if you try to create a new header using a header number which you know already exists? Does the field rule trigger an error message?

If no, something is wrong with the field rule for sure.

If yes, then what exactly are the network and multiuser conditions which permit the duplicate to be entered?

Bill

[John Lemisch]

RE:

Bill, I have an installation where the field rule sometimes allows duplicate records, even though the rule is set for the value of the field to be unique. I can't create the problem on my own network, but it does happen on the clients'. The workstation being used is win98se on a Win 2000 server. The server is using NTFS. I suspect there are network problems, i.e. cards, cable, etc., but don't really know.

[Robert Bowman]

RE:

I don't get the error message. My only alert is that it brings in the browse from previous entry (actually the browse records loose their association with the original header record).

I plan on transfering records and application to a temp directory and zapping the temp dbf's to see if it clears the problem.

I'll let you know.

Thanks

Bob

[Robert Bowman]

RE:

John / Bill

I have not tried v5 on my computer -- only on a local server. However, I get the same problem using v4.5 for this application on my computer.

Bob

[whanigsberg]

RE:

The rule is not being enforced. Have you tried deleting and reentering it?

Bill

[John Lemisch]

RE:

If that last post was to me, Yes, I have. Out of around 900 records entered each week, there are usually 3-6 that are duplicated. Of course, the user entering the data is working from individual, unique invoices and should not be entering them a second time anyway, but it certainly is making "idiot-proofing" this app a challenge. When I go remote on their system, and try entering dupicates, I cannot. Since I am always in the system after hours, it seems logical to me that it has something to do with network traffic during business hours. Thanks for the reply Bill. Any other takers?

[Robert Bowman]

RE:

John / Bill

I think I've discovered the cause. Inorder to know which requistion numbers have been used I had the field as a lookup -- based on previous values. This worked with v3.

To get around it I've established a dbf with one field (req_numb). I wrote a script that runs an append operation. It works with the exception that I get a notice asking me if it's ok to append records. I tried to make the script run silently -- but the run silent option selected it will will not append the field.

Is there anyway that I can automatically append with out having the message appear on the screen?

Thanks for your help.

Bob