fmwebschool.com
Top Experts [learn more]Top 4-10
webko

9743 K
bandmandq

2458 K
Genx

1525 K
4. tcmeyers
5. kbata
6. Martie
7. Hammerton
8. rrenfrow
9. bneeman
10. plegler
Welcome, Guest. Please login or register.
October 31, 2014, 03:43:28 PM

Login with username, password and session length
Search:     Advanced search
FMWebschool releases more educational FMStudio webinars - check them out here:
http://www.fmwebschool.com/webinars.php
27809 Posts in 6154 Topics by 1525 Members
Latest Member: alkyred
* Home Help Search Calendar Login Register
+  fmwebschool.com
|-+  FileMaker Inc Products and Technologies
| |-+  FileMaker Server 9
| | |-+  FileMaker Server 7 / 8 Advanced
| | | |-+  [SOLVED] records disappearing
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Print
Author Topic: [SOLVED] records disappearing  (Read 6006 times)
fchieli
Newbie
*
Offline Offline

Posts: 16


[SOLVED] records disappearing [Was worth 100 Kudos points!]
« on: January 26, 2008, 12:16:20 PM »
See Answer

Hi, I've been pulling my hairs with a particular client of mine.
I've developed a solution for them, simple stuff, 5 tables.
It's hosted on their network, but I don't have access to the server.
I know the server is version 8 or better.
Now here's the problem: from time to time huge blocks of records are disappearing, consistently and in record ID order. So every record from rec ID 0000 and 3000 are now gone.Anything after 3000 is there etc...Then a couple of months later everything from 3000 to 5000 goes!
Now I have to exclude employees deleting records, I've created a tracking system that tells me who deletes what, I've trained them over and over.
I checked every (very few scripts involved) and every relation (none of them will trigger a related record deletion).
I'm starting to think there's something wrong with the server or with the way is getting backed up. Their IT person uses Retrospect, which I don't think is the way to go. Could the backup software or a crash or something be causing the records loss? The weird thing is that all of this is happening only on one table...
Logged
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2116
Kudos: 9743



WWW
Applications:
« Reply #1 on: January 28, 2008, 04:27:54 PM »

Using Retrospect directly is not good - the files need to be backed up locally by FM Server, *then* Retrospect can take those backup files and store them somewhere else.

However, that in itself should not make records disappear, it will just create corrupted backup files which are basically useless as backups.


But I don't have an answer as to why records are disappearing like that - and are the recIDs really that round for the disappearing records? I'd also check out FMDiff to check for file corruption, just to be sure that table is OK...
Logged

tim.webko_at_gmail.com
fchieli
Newbie
*
Offline Offline

Posts: 16


« Reply #2 on: January 30, 2008, 12:42:31 PM »

No they're not that round, it was just an example.
Now all that is left in the system is records with record ID above 8134.
When they started using the solution first record ID was around 1000 or so.
So when the data loss happens, it always affects older record in blocks, I can affirm this because I see that the records that survived are perfectly sequential (8134, 8135 etc...).
A little bit about the solution itself:
I have an Inventory table a Loan table and a Borrowed items table.
Inventory contains clothing items, when they get loaned the employee creates a loan, with basic info etc...and then adds items from inventory to the loan. This actually creates a line item that exists in the Borrowed Items table.
The records in the Borrowed Items are the one disappearing. No one can access the Borrowed Items table records directly. They're visible only inside a portal on the Loan layout and they can only deleted via button/script, one by one (no delete found records available).The script also logs who has deleted what and there's no record showing anyone deleting more than a few items here there(if they add items by mistake).
No record can be deleted via relation.
So I narrowed down this to:
Server Problems (Backup related, Server crash or memory problems or the server hitting his limit of databases/records being hosted).
or
Their IT guy messing up and trying to restore and reimport data after a crash (this though I will never know, because and I don't have access to the server...)
Thanks for your assistance!
Logged
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2116
Kudos: 9743



WWW
Applications:
« Reply #3 on: January 30, 2008, 02:00:48 PM »

No they're not that round, it was just an example.
Now all that is left in the system is records with record ID above 8134.
When they started using the solution first record ID was around 1000 or so.

How do you identify the RecordID - is it an auto-enter serial calc or the actual, real FileMaker -recid ?

Quote
So when the data loss happens, it always affects older record in blocks, I can affirm this because I see that the records that survived are perfectly sequential (8134, 8135 etc...).

True FileMaker -recids are not actually sequential, although they will appear to be for some large blocks, but I don't think this is the issue at hand

Quote
A little bit about the solution itself:
I have an Inventory table a Loan table and a Borrowed items table.
Inventory contains clothing items, when they get loaned the employee creates a loan, with basic info etc...and then adds items from inventory to the loan. This actually creates a line item that exists in the Borrowed Items table.
The records in the Borrowed Items are the one disappearing. No one can access the Borrowed Items table records directly. They're visible only inside a portal on the Loan layout and they can only deleted via button/script, one by one (no delete found records available).The script also logs who has deleted what and there's no record showing anyone deleting more than a few items here there(if they add items by mistake).
No record can be deleted via relation.

All of this sounds reasonable, but I would be double-checking every relationship into the BorrowedItems table to be certain there is no Delete Child allowed...

Quote
So I narrowed down this to:
Server Problems (Backup related, Server crash or memory problems or the server hitting his limit of databases/records being hosted).

Highly unlikely under most circumstances - all of these may lead to a corrupt database which requires repair, but not to records being removed.

Quote
or
Their IT guy messing up and trying to restore and reimport data after a crash (this though I will never know, because and I don't have access to the server...)
Thanks for your assistance!

This sounds more likely, especially if the record id you are talking about is a serial number of some sort.

One other thing - do you have an old copy of the database with old data - see if you can find a borrowed item that is actually the same as one in the current version in every respect except the record id (ie, same Inventory item, borrowed by the same person on the same date)...
Logged

tim.webko_at_gmail.com
Michael Petrov
Chief Software Developer
Administrator
Hero Member
*****
Offline Offline

Posts: 4286
Kudos: 15522




Applications:
« Reply #4 on: February 05, 2008, 05:09:22 AM »

Perhaps some script is deleting/readding all the portal rows - keeping everything else the same but the delete/create (which looks like a move operation) creates the new record ids? And as webko has mentioned, delete child relationships have to be very carefully double checked.
Logged

Michael Petrov,
Chief Software Developer
FMWebschool
800.353.7950
michael@fmwebschool.com
Keep up with our development, follow me on Twitter
fchieli
Newbie
*
Offline Offline

Posts: 16


« Reply #5 on: February 05, 2008, 02:53:15 PM »

I checked every relations that involves Borrowed Items so many times... Cry
and today I did again just in case.
I've saved a copy of the solution with some current data, if anything happens I will be able to compare...
I've also implemented a new field, autoenter, serial number , so I will know what's happening.
Also removed the ability to delete from that table for any user that is not the admin (only I have the admin pass), they can remove records via button(connected to a script that runs with full privileges, but logs every action into another table and can delte items only one by one...)
Thanks for you r help!
Logged
FMWebschool
FMWebschool Team
Administrator
Hero Member
*****
Offline Offline

Posts: 1026
Kudos: 1383


Allyson Olm, Chief Developer


WWW
Applications:
« Reply #6 on: February 15, 2008, 06:47:27 AM »

Hi,

Did your question ever get resolved?  Please let us know.
Logged

In Kindness
FMWebschool Team
http://www.fmwebschool.com
http://www.fxforge.net
800.353.7950
fchieli
Newbie
*
Offline Offline

Posts: 16


« Reply #7 on: February 21, 2008, 10:43:42 PM »

I have not heard from the client in a while...
I know their IT person stopped using Retrospect...

Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!