Error #13

[Homer]

While publishing a FileMaker 8v2 database thru IWP, an error message: "unknown error number 13" will eventually appears on the browser as a pop-up window... This error can happen at any time and we are unable to figure out what is the cause of this problem.

On the server-side, when the 'error 13' happens, we have to restart the two(2) WPE services and then everything is back to normal. But it is not an acceptable solution !!

The phenomenon is the same on two different Windows servers we tried and NO, this is not a matter of a corruption because it is a totally new and clean file.

The server is running FMSA 8v2(release# 8.0.1.28) and the browsers are either IE or Firefox.

The web publishing log files didn't help much here.

Is it possible that a field validation rule or maybe a tricky script can cause the problem ??

Any hint will be greatly appreciated ! Thanks !!

[Genx]

... If i recall, Error 13 is an "object is already in use" error...

I know it's not much help, but there you go.

~Genx

[Homer]

Thanks Genx for your reply. Actually the exact error description is : "File or object is in use". But what object is it about ?? I really don't know.

Unfortunately, the support of FileMaker Inc. doesn't help us on this. We call them in California but they are unable to find a clever solution. }:(

[Zero Tolerence]

Happens to me all the time too. The only solution we came up with was to create a batch file to restart those services, and then schedule a task to run it every so often. Again, not a great solution, but it helped lower the amount of times I had to manually restart those services.

[Genx]

I'm fairly sure it has to do with the file itself.. i.e. your calling a script and filemaker loops on itself trying to call your current file?

Dunno, just a thought.

~Genx

[tbill]

I am having the same problem at a client site - here's what's interesting about this. We hosted our client's db for 5 months using the Mac Xserve dual G5 - never a problem, always working okay. We then moved it to our client site and within a few days error 13 popped up - they are using a Windows 2003 Server! I can't figure this one out yet, making me a very nervous man...

[Homer]

[sOLVED] Thank you to my guru-friend for solving this one!

If a user allow his web session to timeout after a field-validation rule has failed, then the error number 13 may appears on the client-side(browser). The validation rule doesn't need to be 'strict' for this phenomenon to happen.

Once the error 13 has been reported for the first user, then other browsers that attempt to enter an IWP application on this server may receive the same error code and may be unable to enter.

Instead of restarting the WPE services twice a day, I think a solution will be to use built-in field validations with caution. Using scripts to validate the data entry is probably a better idea in this situation!?

I guess we can call this a 'bug' in the Web Publishing Engine of the FMSA and based on the previous testimonial by Tbill, this 'bug' seems to be specific to Windows servers.

HTH

[ClifG]

I will add that this is happening on an OSX hosted IWP application I have so it is not Windows only.

[Homer]

Thank you ClifG for this important detail. I didn't try it on a Mac Filemaker server yet.

My client and I found that a very big problem with this bug is the fact that other users who are entering the IWP application after the error 13 happen could be transported to the last "invalid-validation" record. Whatever this record is about...

In our case, we have confidential student profiles and the next student to log into the IWP app has many chances to be driven to another student record because this record wasn't validated correctly before his web-session ended.

This invalid-record is kind of 'locked' by the FMSA!

:)

[tbill]

Hi Folks,

Okay so I've read all these threads about error 13 and I need to add some additional concerns. first, I was using my XServe G5 for 5 months without one error, I only transfered the databases to a windows server and right away got the error 13. Now each day this happens. I have reviewed all the scripting errors as posted in the logs and still error 13 happens. So I put the databases back on my XServe and voila, no problems, no error 13.

I have a few fields with validations (not strict) but I've always had these and it's only on the windows box that this problem happens. Can someone explain what they did to make these errors stop? Is the fact that the Server and IWP are on separate boxes a consideration because my Xserve hosted both, perhaps the windows box should host both?

Any thing would be helpful to me, should I remove all instances of field validation because it is a windows box?

Cheers,

Terry

[ClifG]

I didn't have a clue what is really causing the error 13 but there was an explanation that was reposted to me.

""An Update: IWP Unknown error number 13"

There have been a few reports lately about getting error 13

using IWP. The problem occurs when a user allows the session to time out

while in edit mode with outstanding failed field validations.

For example:

1. Create a database with a field that has a validation of "Not

Empty," and share it via IWP.

2. Set IWP session timeout to small value (e.g. 1 min).

3. Log into the file from a browser.

4. Click New record button.

5. Wait for 1 minute session limit to expire.

6. Click Submit button (should get Bad Request session timeout message).

7. Click on database name from homepage again.

Result: "Unknown error number 13."

Currently the only workarounds are to remove unneeded field validations, or

to make sure users commit records and/or log out rather than letting

sessions expire in edit mode. The latter isn't necessarily so great

for a public site, but might be OK for a small office group using IWP.

As more information becomes available, I'll keep you informed.

____________

Simms Brooks, Technical Liaison, Developer Relations T: 408 987 7317

FileMaker, Inc. 5201 Patrick Henry Drive, Santa Clara, CA 95054, USA "

This seems to make it clear that validation is part of the problem. So I looked at my app and it had almost no FM validation. (I used scripting to post validation error messages to screens vs FM validation) I found two instances which I had forgotten about and removed them WHICH MADE NO DIFFERENCE AT ALL.

So what was pooping my #13 was not anything to do with validation in may files.

What did I do? Well I reprogrammed the app to be one file vs 2 and replaced most portals with finds and lists. I also replaced table lookup pull down menus with fixed value list where I could. The resulting app runs faster on the web and has fewer #13 errors (one in 2 weeks vs one a day).

Clif

[Homer]

For Tbill :

perhaps the windows box should host both?

In my case the error 13 happens on 2 different setups but both setup is a one(1) Windows machine schema. :

For Clif: Are you sure you don't have other files hosted on your server Advanced that includes field validations? Maybe the file who's causing your error 13 is not the file you are currently working on!?

I ask this because as you know, we can host up to 125 databases on the same server.

Don't give up now guys, I personally think this FMSA is an outstanding peace of software. However some improvements are necessary.

[tbill]

Hi Folks,

I've called Filemaker and their response is that although they support 2 and 3 pc configurations, the 3rd and 2nd pc fail at times without any valid reason. The hardware might be an issue is what they have said. they also indicated that a one box solution is the best approach to solving this issue.

Please note: they also said that they have no record of anyone else complaining about error 13 or 20603. they further mentioned that 99% of users one a windows box using 2003 server have no problems so because i am almost exclusive, it must be something I've done.

My clients are huge and I have another client wanting my software in the near future but I can't encourage their use of the product under windows and they won't go to the mac so I am not a happy camper...

Terry

[John May - Point In Space]

That's a bunch of BS that they haven't heard of other error 13s, FYI. I know, because we have reported such directly to them as well. They told us the problem has existed since FMSA 7, and they haven't been able to 100% nail it down yet.

- John

[tbill]

So, here's the latest on our attempts to solve the error 13 issue. Filemaker says that a two or three server configuration is not solid that a one server configuration is. So we are about to roll back an entire implementation to a one server configuration. The client is not happy about this and neither am I. I have several more clients ready to purchase our enterprise solution but I admit that I am concerned about the error 13.

We've tried everything, removed every instance of a field being validated, we've ensured that the windows server is the latest with only a minimal amount of system resources. We've tried restarting it every morning at 6:30 but sure enough by 9:30 an error 13 is reported.

So as I've said, I am about to roll it back to a one server config to see if that solves the issue. Our Mac server was a one server config with no problems so we're prepared to try this.

Can anyone shed some light on what to do, this is very serious at it crashes the web server each and everytime..

Cheers.

Terry

[tbill]

Okay, so here's the latest news. We've checked every ounce of our code, fixed anything that appears as web scripting errors on our pe_application error log file and still no luck getting rid of error 13. In fact now we are getting error 100, 102, 112, 105 and 20603 every day, all day long. We need to restart the service at least twice a day with no pattern other than the error messages. These are not IWP error messages, these are FMP error messages. So in a conversation with FMP support (again) we got this really good guy who told us the following:

1) This is a windows specific error and FMP is aware of it

2) My ticket has been escalated to engineering because of the severe error codes being produced

3) I should cease doing anymore work at trying to solve this issue from a coding point of view, it is not my code. Which is a relief. Keep in mind that we are running a parallel version of the db on our mac server and have never experienced a problem after 6 months.

4) Error 105 is a memory error and we should set the memory to static from virtual

5) Make sure if you are using IIS that no other web servers are being hosted

6) We should patch to 8.0.3 to see if that helps

7) We should disable SSL to see if that helps as a temporary test only

So if you are restarting your server twice a day as we were and we are still getting error 13 plus the others, then move off the windows server 2003 back to a mac.

Also, rolling back to a one server configuration from a two server (one fmp server, one IWP) that won't solve this problem. The solution seems to be with a bug in IWP and a major one at that.

This is so big a bug that we can't sell our solution to any other customer on a windows environment. This will cripple our business this year.

Any one have any real solutions that they can share about error 13?

Cheers,

Terry

[mshanta]

Has there been anything new on the Error 13 issue?

[Chris Irvine]

FYI, we are experiencing a similar problem, but from a different angle.

Our setup...

Server G5 xserve 8.0v3

2nd server G4, custom web publishing engine

The web publishing engine seems to get into a broken state 2 or 3 times a week. Lucky for us, we discovered that loading a request for a list of databases "-dbnames" twice in a row, seems to reset the broken state.

I'm collecting some of the details now, and will post a complete description of what we know to the FM Server Advanced subforum.

[Homer]

It seems the revision v4 for the FMSA 8 fixed the "error 13" problem?

It is not part of the official fixes but some days ago, someone posted a message about this on another forum... And I simply want to know if the feedback on fmforums's visitors is the same.

THANKS

[GoTigers]

Per FileMaker, revision 4 of FileMaker Server Advanced version 8 does NOT fix the error 13 problem, but I was told by the rep that the problem has been "trapped" and so it may be fixed by the next revision.

This problem has given me fits as I've had to remove all field validations and try to come up with scripted validations, and I've been unable to conquer one specific area. Anyway, hopefully soon!

[IreneL2]

Too bad about your Tigers. I was rooting for my favorite player, Pudge.

About Error 13, is it more than just a timeout problem? I was able to uncheck the boxes that disconnected idle users from the server. It will still kick them out but at least they can sign back in.

Anyone know if I can change the time out time for my web users to a greater time than 15 minutes?

Thanks,

Irene

[GoTigers]

Yes, the error 13 thing causes the database to be unavailable to all users. Anyone who tries to log in gets the "error 13" message, and then you have to restart the server to clear out the error.

The TIgers had a wonderful, improbable run this year. The ending was a disappointment to be sure, but I'm all the more eagerly awaiting next season!