Jump to content

This topic is 8719 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I have been in the process for nearly a year of writing a demonstration of cdml/html for FileMaker developers, particularly those who are finding themselves being asked for the first time to develop browser based solutions for their employers and/or clients. Affectionately known as newbies, they face a learning curve.

When I was a newbie, I already knew html and as I started trying to learn the language of cdml I struggled with the lack of good examples. I read a couple of books which helped, but it was a struggle. And some of the information in those books was flat out in error. So I decided to write my own demonstration of what I would have liked to encounter.

I have developed a demonstration entitled

Posted

quote:

Originally posted by Keith M. Davie:

SCRIPTS. What would you pay to find a workaround so that you could run scripts in you web / browser solutions with confidence? You
Posted

Anatoli, I wondered if I would hear from you. You are, after all, the one who made me aware of the problem. How can I convince you? What, you don't believe me? Hey, I am one of the most honest persons around. I would not have made the claim otherwise.

Please contact me personally, kmd@njwintrup.com.

Peace

Keith.

Posted

I am not disputing your honesty.

I do believe you are convinced that you have solution. But I am the one not convinced.

On the other hand I will gladly admit when I am wrong. And if you found the way which I can test and confirm your outcome, then I will pay you the money and endorse your solution with my authority whatever level I achieve.

Anatoli

P.S. I am sending you this by e-mail as well

Posted

Yes I am also ready to force my university administration to pay that money in case that it can solve our script problem in using them over internet in multi-user area without any confilict of the scripts running during 10 seconds.

But not me they should be convinsed in any way !.. ( the one that should be convinced is the vice president who is a program devoloper on other platforms )

Abkaplan

[ April 07, 2001: Message edited by: abkaplan ]

Posted

abkaplan, tell your boss that the demonstration being offered includes a workaround. A workaround allows you to do just that - work around the problem. The problem is not solved - it is worked around. So perhaps we should understand the problem first.

The problem is that Web Companion is single-threaded, i.e., it handles one request at a time. All other requests are, at best, ignored. And we have seen that in a multi-user environment such as the web, if near-simultaneous requests for ScriptMaker scripts are received, the problem can be expressed by the clients being advised that their transactions were successful, when in fact one of the scripts went completely un-run - the transaction was not successful. There may be additional undesired results.

The only safe solution to that multiple request problem has been to avoid using scripts in browser based solutions.

I have developed a safe workaround.

Does it solve the single-thread problem of Web Companion? Of course not.

Does it allow scripts to be safely run in the web environment? Yes.

Does it allow the developer options? It most certainly does.

If the developer chooses to use the workaround, then the developer can do so knowing that data will not be compromised within the database files as a result of multi-client requests for scripts, nor need any client be inadvertantly incorrectly advised of the status of their activity.

The workaround is a combination of database structure, script structure, and the structure of the format files.

Using the workaround, if a near simultaneous request is made on ScriptMaker scripts, the client whose script is not run can be asked to resubmit their request.

Some developers are not going to want their clients to re-submit - ever. They are afraid that they will offend their clients. They do not need options. They do not need the workaround I have developed.

Some developers are going to look at the workaround and say, well, it's not as ideal as making Web Companion multi-threaded, but it does work and it does protect data and it does allow scripts to be run safely.

And some developers are going to say, well I can use the workaround here, but I cannot use the workaround there - and it is good to have that option and to know when to apply it and when to not apply it.

So I guess that if you do not want your clients to ever have to re-submit some data or a request, the workaround is not for you and your developments. Don't bother spending your money on my workaround.

On the otherhand, if you don't mind an occassional re-submit responsibility being placed on your client, and if you feel that you can develop creatively to make those resubmissions as painless for the client as you possibly can, and if you are able to structure your development so that not many scripts are required, and if you want to run a script or two safely, and if you like having as many options as possible to consider for your developments, then this workaround may be just what you are looking for.

And the workaround is but one part of a larger package which was developed for developers. As such, you may find another useful tool as well. For what the demonstration includes, I believe you will find it a very good value.

SIMPLIFY

Keith

Posted

>FileMaker will still crash or stall if 2 people will try to run scripts.

Well I understand the reasoning in that statement.

However the reality which I experienced consistently in testing this by making simultaneous calls was that the first call received was the call processed and the proper results page made to appear to that client; and the second call was not processed and a results page reflecting that result was made to appear to that client.

We can argue about whether or not it should work. I tested it extensively by making near simultaneous calls before I proceded with re-writing the demonstration. I am interested neither in wasting my time or embarassing myself. In every instance it worked as I have stated. There was no crashing. There was no stalling. Had there been, I would have stopped working.

I also realized that one can structure things incorrectly and cause the stalling and crashing. But structured properly, I have been unable to produce the theoretical results of which Anatoli warns when I have called two scripts near simultaneously using the workaround. Without the workaround, those adverse results were easy to accomplish.

I agree that logically, using a script to see if a script is running sounds like it will guarantee a crash.

However, using electricity to see if electricity is present may not be so problematic. Or is it a case of using electricity to make sure other electricity can not be present?

Whatever it is, I have been unable to produce the adverse results when making a near simultaneous call of scripts on the workaround. Yet I have been able to produce consistently the positive results which I have reported when making near simultaneous calls of the same scripts using the workaround.

Peace

Keith

Posted

Yeah but with your "workaround" you cannot guarantee "near simultaneously". You just wish that it would be the case.

If you run scripts under 0.01 sec, that can be the case in 99.99%. Still no good in my solutions.

If you run the scripts in 1 sec, that crashing may occur in 1-20%.

If the scripts will be running longer time (e.g. in all records in large database) the crashing will occur in 50-99%.

Posted

Anatoli, I have posted my results. My results are that the workaround in my demonstration is successful when more than one request is made for a script.

You claim that it will crash. Please, make it crash and then post the step by step of what you did to make it crash so that others may duplicate your work. As far as I know you have been unable to make my workaround actually crash. As far as I know you have only theory not fact to support your position.

Please make my workaround crash through multiple requests for the scripts. And please tell me step by step what you did to accomplish the crash, not just that you claim that you did. I want to be able to repeat what you claim by using your step by step process. I have only been able to get the successful result (i.e. no data loss and each party properly informed) to repeat. Those are my results. I am really curious how you will accomplish the crash. You claim it can be done. Surely you can demonstrate it to me. You were able to demonstrate the problem which occurs without the workaround such that I was able to repeat that.

Peace

Keith

Posted

quote:

Originally posted by Keith M. Davie:

Does it allow scripts to be safely run in the web environment? Yes.

Obviously NOT.

The "workaround" relies on SCRIPT (!) to check if somebody is running Script.

In another words, the problem with single threaded FM is just elevated up to another level.

FileMaker will still crash or stall if 2 people will try to run scripts.

Just to be fair, Simplify is good start for someone trying to get into FileMaker database web publishing.

Posted

Anatoli, on Sunday 04/08 you wrote, "Yeah but with your "workaround" you cannot guarantee "near simultaneously". You just wish that it would be the case."

What do you mean my workaround "cannot guarantee near simultaneously"? My workaroud is designed to prevent collisions when two or more requests are made for a script in a web based solution in near simultaneous calls. It is not designed to guarantee that near simultaneous calls will occur. It is designed to prevent problems when those near simultaneous calls do occur. And it works as designed. It does not crash. It does not send the wrong message to the anyone. It does not cause problems with the data not being manipulated because a script did not run. It allows the client to resubmit the data. All as designed.

The results which I am getting clearly show that the calls are being made in a near simultaneous manner.

You say it will crash. Then why do I get the results that it did not crash every time that I have made a near simultaneous call for a script?

And the scripts which are being called in my demonstration and which are giving these positive results take longer to run than the 0.01sec. of the script you are using (unprotected) in your solution. My longer running scripts are not crashing with my workaround. My workaround is working as designed.

SIMPLIFY

Keith

Posted

I am getting bored. 2 users cannot run in the same moment script, scripts in the same file or in different files!

PERIOD!

Start script in one database in loop.

Then start another script e.g. your "workaround".

What happened?

Posted

Anatoli, I am sorry you are getting bored. However, it appears that you have not crashed the workaround in the demonstration which I sent to you.

I know nothing of a loop. Perhaps you would be good enough to send me the loop to which you have referred and the manner in which you ran it against my workaround. I gather from what you posted that you have actually done this.

Thanks, I appreciate your input. If there is a problem, I will see if it can be solved. But until you provide the loop and manner in which you ran it, I'm afraid I cannot even attempt to fix the problem which you claim to have created.

Using the demonstration which I sent you, have you been able to make that crash?

SIMPLIFY

Keith

This topic is 8719 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.