Jump to content

VolkerKrambrich

Members
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About VolkerKrambrich

  • Rank
    novice
  1. What you want to do: Inside the standard folder for FileMaker Server backups, do create a folder and name any way you like it - "MyCopyForRemoteSite". Now create a schedule in FMS Admin Console to save your database file(s) once a day into that folder, keeping only one version (meaning overwriting the contents tomorrow.) Now you have the folder where to look for data from you system script; that script will first prepare, then push (copy) the data to the remote site. In my scripts. I first copy data to my work directory, then use zip with the options -rj (r traverse directories
  2. Jorge, on an x-serve with MaxOS server, go to terminal, run the commands (fmsadmin...) to check the FileMaker server status, then stop the server. (user and password detection as described yesterday). This advice was given by Steven already. If you do not have the user/password, got to your backup folder (default Macintosh HD/Library/FileMaker Server/Data/Backups/) and check for the latest copies. If you cannot stop the FileMaker Server your databases might by corrupt after you forcefully shut down the service. Now either stop FMS processes via the Activity Monitor and deinstall.
  3. I am not quite sure now wether we're talking about the same thing. 1) You have one physical machine with one virtual machine; win svr 2008 R2 installed on both. From the side of the running win2008 svr on VM viewed, this is a closed, one machine installation. Then you put another VM on the same physical machine. Make sure that the undelying hardware is performant! If you place more concurrently running virtual servers here, they conquer and fight for CPU time. MS Exchange server can be demanding! And if the FileMaker Server in the first machine (which is in fact another piece
  4. Hi, what you want to do is basically looking at the number as a string of digits, than beginning from the right end, take three digit, put a comma in front, then take the next bunch of max. three digits and so on. This might need some checking of boundaries, like number less than 1000 etc. To get you started have a look at Brian Dunnings collection of calculation algorithms at http://www.briandunning.com/filemaker-custom-functions/recentlist.php search for "number formatting". If the only place where you need this is the layout, you could also FM built in formatting. Put a mer
  5. ...another reason could be that access via server admin console was restricted to certain IP addresses or the local network. See server "configuration:general:admin console" in the server settings in admin console (for those who have access). Regards Volker
  6. Matt, you were originally writing about a worker that was not in the list – did a 2-machine deployment work the way you describe?? On one machine I can understand the impact of unplugging from the network, but with the relevant webserver on another machine? Wondering, Volker
  7. Well, as said, FMS9 will eventually not work with Win Svr 2008. FMS11 in a one machine deployment works just fine. No adjustments needed. If you want to use Apache instead of IIS, install and configure and test that before any FMS installation. I just ran quite many tests both on the original "hard pressed" CD version without update and with all Microsoft recommended updates (as of 20. June 2010) installed. No problems. But off course, FMS runs as 32bit service. To my knowledge there is no document from FileMaker regarding any patches. When data is so important and confiden
  8. In FMS9 there is a little security hole that you might be able to exploit. Go to the server log and look for the entries where the server started last. In the middle of the part where all the parameters of the current installation and setup are reported you find the information about admin name and password. Regards Volker Re: I am talking about the FMS log, not the MacOS Server.
  9. Hello DrewAngell, the first thing that comes to mind is file corruption. As you mentioned in another thread you are aware of the basic rules of closing down files correctly before moving them from server. In the backup schedule(s), do you check the files' health? What is in the protocol? Turn on the access protocol in server admin, try to connect and look for the event in the log file. If you take the file local on MacOS, can you open the file with full access? If you make a clone as part of server schedule, can you access that clone if taken local? (Here could be the cure: ta
  10. Thank you Wim for chiming in! Yes, IIS seems to work ok. I put a .php test file into wwwroot and the response shows the FileMaker deployed PHP engine working. No, no other sites. The server is solely dedicated as a WPE companion to publish an interface to the organizations' scientific publications. Volker
  11. Thank you, Steven, (in fact, I thought I was on this forum, but needed to re-enrôle) yes, anonymous acces is on. We can get to the main page through browsers; we can even enter /fmi/iwp which usually results in the IWP homepage being displayed. Here we get an completely empty page returned, i.e. the HTML code consists of wellformed html, with header etc. but no contents besides the tags... Very strange and completely different from any of the problems reported in the forums. I am having the suspicion that parts of the communication between the servers is not betting back to th
  12. Hi all, I found confirmation in this forum that installing on win 2008 R2 is trouble-borne for some of us. I think I have a new issue to report: 2 machines with same server OS. All FMSA runs fine if deployed under either environment. Making one the worker (with ports & versions checked & confirmed), the other one the master, works somehow as expected. Exception: have to enter the worker's ip address since it is located in DMZ. Deployment then works fine. Services on worker get started as expected. BUT connecting to e.g. FMServer_Sample via IWP fails in a special way:
×
×
  • Create New...

Important Information

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