Jump to content
Sign in to follow this  
spongebob

Files remain open

Recommended Posts

hmmmm

I open a Filemaker File called File A.

At some stage in a script I open a File B over the network.

Q1: Is it possible to determine via script with which password rather than just the pw used for file A?

But thats not the real problem. The real problem is:

Then in the script of File A I close File B from with File Close blablbla but it remains open hidden. I have proof of that cuz when I try to quit Filemaker on B, it says A must first log out.

I quit A, then B Quits okay.

This is cumbersome.

Shouldnt a file close break all connections to a file? YES File A has a portal to file B and one script also accesses file Bs fields, BUT if I only open and use file A without running any of my script, File B is never openend and so it should be.

Any idea how I can fix this? Right now if someone used my script to access file B I must QUIT his FM via script to get him out of the file B properly.

And to answer your next question...the answer is...FM 8.5 Advanced baby... :)

Thanx for any brainy ideas...

Spongebobs

Share this post


Link to post
Share on other sites

Shouldnt a file close break all connections to a file?

Unfortunatley its one of those weird kinks with FM. If it really bothers you, just hide the window toolbar item. Why is it you want to quit the file anyway?

Q1: Is it possible to determine via script with which password rather than just the pw used for file A?

Not really understanding that question... In a multi-file scenario though, the idea is that you have duplicates of accounts and password in each file. That way if you have an account called "alex" pw "alex" in FileA, and an account called "alex" pw "alex" in FileB, after logging into FileA, FileMaker attempts to login to FileB with the same credentials...

Share this post


Link to post
Share on other sites

Quote:

Shouldnt a file close break all connections to a file?

Unfortunatley its one of those weird kinks with FM. If it really bothers you, just hide the window toolbar item. Why is it you want to quit the file anyway?

-- because in this system, several remote files will log into a master file to occasionally dump data to head office. And when they are done dumping I want them not to be connected anymore, otherwise, with time, the head office file will have many folks logged on and I cant close it anymore.

So why not do everything centralized over the web I hear you say? Because its a db with 1200 fields and thats too unergonomic and cumbersome to enter over a web form.

Quote:

Q1: Is it possible to determine via script with which password rather than just the pw used for file A?

Not really understanding that question... In a multi-file scenario though, the idea is that you have duplicates of accounts and password in each file.

-- no because if a user changes pw in file A it wont automagically also change in file B. The mere fact that he accesses file A should in this case give him access to file B even if he changed his pw in file A. But I dont want everyone accessing file B with the same pw...so id like a few logins and hardcode a pw...from a field. Doable?

A candle loses nothing by lighting another candle -- but nothing is gained either if the room is currently dark... :)

any ideas?

Share this post


Link to post
Share on other sites

Okay, lets take them one at a time:

So why not do everything centralized over the web I hear you say? Because its a db with 1200 fields and thats too unergonomic and cumbersome to enter over a web form

Well, yes but, IF you have Server Advanced you may just be able to have headoffice query your database files directly via XSLT or the FM PHP API.. Its a lot more effective and doesn't really rely on your databases sending any files anywhere.

The mere fact that he accesses file A should in this case give him access to file B even if he changed his pw in file A.

Are you describing your scenario here? i.e. File A is your Local File File B is your remote head office file?

Share this post


Link to post
Share on other sites

Because its a db with 1200 fields and thats too unergonomic and cumbersome to enter over a web form.

Yikes! Any form with 1200 fields is going to be cumbersome. Is that normalized?

Share this post


Link to post
Share on other sites
its a db with 1200 fields

Share this post


Link to post
Share on other sites

Genx you discripe this:

And when they are done dumping I want them not to be connected anymore

As one of the kinks? Aren't you using it as feature allowing the separation model to actually seem to work??

--sd

Share this post


Link to post
Share on other sites

Hey, if you're gonna make a point, make a point. We're kinda slow on this side of the pond.

Share this post


Link to post
Share on other sites

LOL! Database consisting of many tables (and assumably many layouts) vs 1 Form / Layout.

Share this post


Link to post
Share on other sites

As one of the kinks? Aren't you using it as feature allowing the separation model to actually seem to work??

I wasn't trying to get at the fact that the connection itself doesn't snap when you try to close a related file but rather: I only use one interface file -- I don't explicitly open those data files nor will i need anything but access to the data itself in those files -- hence the windows being opened (hidden or otherwise) aren't really of any use.

Share this post


Link to post
Share on other sites

Well a form implies it's all part of the same process (if not the same layout), which is why I posed the question. I can't imagine any process that would require entering data into that many fields (in a normalized solution or not). In any case, you can't always take for granted that someone's "db" is a file with multiple tables rather than a file with one table. If the later, then normalizing could solve some of the current issues. Never know.

EDIT:

The "1200 fields" reminded me of this:

http://fmforums.com/forum/showtopic.php?tid/147389/

See, it ain't my imagination. It does happen.

Edited by Guest

Share this post


Link to post
Share on other sites

Yeah okay, point taken.

Share this post


Link to post
Share on other sites

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
Sign in to follow this  

×

Important Information

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