Files remain open

[spongebob]

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

[Genx]

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...

[spongebob]

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?

[Genx]

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?

[Ender]

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?

[Genx]

its a db with 1200 fields

[Søren Dyhr]

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

[Ender]

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

[Genx]

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

[Genx]

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.

[Ender]

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 May 22, 2007 by Guest

[Genx]

Yeah okay, point taken.