Passord&Login

[gowrann]

I have a fmp 5 database which i have made web ready through Lasso WDE/Webstar & Go Live plug in.

There are 10 clients who create new records for requests on certain criteria

What I would like to do is have each client have a passowrd/login-ID on the index page (not a default "pop up" browser user entry) to access/edit/create and delete only their records not the other clients.

How is this possible.

Many thanks for any help

[Keith M. Davie]

In addition to providing a workaround to safely run scripts over the web, my demonstration "Simplify, Custom Publishing Basics for FMPro Solutions, A Browser Demonstration of html/cdml" also demonstrates entry by a client using a password to get to their one record. Understanding how to achieve entry to one record, you can then expand on the example to find all records belonging to that client. See the postings in the CDML forum "SIMPLIFY -scripts safely run on the web"

CDML is an early version of Lasso, so you will understand the tags.

SIMPLIFY

Keith

[Anatoli]

quote:

---

Originally posted by Keith M. Davie:

In addition to providing a workaround to safely run scripts over the web,

---

Keith,

you are decreasing your creditability by claiming the above.

If you will continue to do so, I will put up my voice against that LOUD!

Anatoli

[Keith M. Davie]

Anatoli, my credibility is intact. I have run the tests on the workaround. I even wrote a specific test to meet your criteria which the workaround handled successfully. You have never stated that you tested the workaround in any manner. You have only stated your unfounded opinion about what you think it will do. I offered you the special edition with the specific "Valid Test" you wanted me to run (why did you not run it yourself instead of having me do it?). You have not had the courtesy to respond to my offer regarding the special edition. Thank you for your honesty regarding what you did and did not do.

SIMPILIFY...

Keith

[Keith M. Davie]

Anatoli, you say you ran my script and it did not work. Which script or scripts did you call simultaneously? From which format file(s) did you run the script(s). What browser or browsers did you use?

In order to see what problems you had, it would be fair of you to inform me. You have never informed me of what you did, either by email or on these forums.

If you ran your loop script, how did you incorporate it into the solution. What code did you write into your loop script to make it work with the workaround?

Surely the fair thing to do would be to inform me of what you have done. You have never given me any hint that you did anything more than surmise that it would not run.

You may refer to what I am saying as bull...., but you have provided me with nothing other than an unsupported opinion.

SIMPLIFY...

Keith

[Anatoli]

I've learned one word in UK, which is describing best your reply and it is starting with bull.

I've run your solution and it DID NOT WORKED. Period. I've written that to you.

If people want to pay you for that, that is fine with me. Be rich.

To execute 2 scripts in 1 copy of FM in the same time, well you discover Perpetum Mobile.

I am nominating you for Nobel Price.

Anatoli Kohout

FileMaker Tech. Support

East Europe.

[ April 11, 2001: Message edited by: Anatoli ]

[Anatoli]

Couldn't we start with test if FM can in the same moment execute 2 scripts in parallel?

[Keith M. Davie]

You would like to discuss theory. That is fine.

I sent you the demonstration so that you could test the workaround, not discuss theory. That is what you indicated you wanted. How was I to convince you, you asked. Simple answer. Provide you with a copy of the demonstration so that you could run fair and valid tests on the workaround.

Let us recall what the workaround does. It works around the single-thread handling of script requests by Web Companion when more that one script is called in a near-simultaneous manner.

How does it do this? If one script is already running the workaround works by prohibiting another script from being run. How do we know it works? By testing.

What will the results show? First we must understand the results if the workaround is not used. Without the workaround, behind the scene for the clients, in the database files, one script will run and one will not run, the database files will stall or freeze awaiting human intervention on a "Continue" button in the Status Bar; and on the scene (in the bowsers) for both clients who called the script in a near-simultaneous fashion, both will be advised that their transaction was successful.

Understanding what happens when the workaround is not used, now consider what occurs when the workaround is used properly. The workaround will show behind the scene that one script was run and one script was not run and the db files neither stalled nor froze and no "Continue" button appeared in the Status Bar. Additionally, the client whose script was run successfully is so advised and the client whose script was not run is asked to resubmit their data.

You wanted to be convinced. Discussing theory and running a test on the workaround are two entirely different things. So far, and by your own admissions, you have not run a test on the workaround. All you have done is propose theory and ridiculous tests.

You spoke of running a script which contains a loop and which takes 20 minutes to run. There is no loop in the workaround demonstration.

Are you suggesting that you would design a web solution which would run a 20 minutes script? If you did that, and if a client called your 20 minutes script, that client would sit there staring a a frozen browser window until the script finished running. If another client were to near-simultaneously call your 20 minutes script, that client would also sit there for 20 minutes (at least) staring at a frozen browser window. You would have me, and others who have been following this, believe that this is a reasonable and valid test. You would have us believe that you would design a web solution which requires your clients to wait for a 20 minutes script to run. Ok, you have given me enough evidence to believe that you are that kind of developer / designer.

Now would you like to know the difference between what would occur with your 20 minutes script if you ran it without a workaround and a near-simultaneous call were made on that script? This is not theory, this has been tested. Without the workaround one script would run successfully in 20 minutes and that client would be so advised, the other client would also sit there and wait 20 minutes while the script ran. Then that client would be told that their transaction was successful, even though the transaction was not successful. And if you had an incrementing field in your database to confirm the successful running of the loop, it would have incremented by 1, showing that only one script had run. Meanwhile, the database files would be stalled or frozen awaiting human intervention on a "Continue" button in the Statue Bar.

If you ran a 20 minutes script with the workaround (and this has been tested), if the second call for the script is made on NN, the script would run for the first client and after 20 minutes that client would be advised that their transaction was successful and the second (NN) client would wait the same 20 minutes to be advised that their request must be resubmitted. And in the background, in the database files, those files would be in fine shape. There would be no stalling or freezing and no button awaiting human intertion.

Same test run when the second call is made by a client using IE reveals that the first client will wait 20 minutes for your script to run and will be advised that their script was run successfully. The second client (IE) would wait another 20 minutes (40 minutes total wait) and that client would be advised that the script was successfully run. In the background the database files would not be frozen or stalled and the field which shows successful running of the loop would be incremented by 2.

How do I know this? I wrote a special loop script and installed it properly with the workaround and then I tested it.

Which gets back to the original point. So far, and by your own admission to me in an email of last Sunday, you have not tested the workaround as it was presented to you. Nor have you performed any other tests on the workaround which were structured to properly account for the workaround. I know this because of what you have posted and my intimate knowledge of the workaround and my extensive testing of that workaround.

Instead of performing even the simplest test on the workaround, you have disparaged my work and impugned my integrity and credibility.

SIMPLIFY...

Keith

[Anatoli]

quote:

---

Originally posted by Keith M. Davie:

Instead of performing even the simplest test on the workaround, you have disparaged my work and impugned my integrity and credibility.

---

Again -- I DID TESTED AND IT DOES NOT WORK, YOU START TO BE REAL PAIN

You are not willing to go step by step through tests.

You are the most self-focused ego I've ever met...

I have more important things to do...

Anatoli Kohout

FileMaker Tech. Supp.

East Europe

[Kurt Knippel]

::Admin hat back on, wooden paddle in hand::

Come on guys, sniping at each other does not help anything. See my previous dissertation on this whole topic.

This thread is closed!