OK, I'll take a stab at this:
1. The client will only hold the GUI file, and there will be a database FM file on the FMserver which the GUI file will refer to for data display. For some reason when I have uploaded my database to my server, the GUI file was unable to call in the data from the file in list view but was able to in individual records view.
Why do you want to do this? Filemaker can very happily allow you to build the Database Structure and GUI all in a single file, or in multiple files, without the need for a local client-side copy of the file. That would mean that each client would have it's own file, which would have to be updated individually. That sounds needlessly complex, unless you're trying to allow for sync'ing of data to the local client copies, which is a different kettle of fish altogether.
2. There should ideally be different layouts for different departments (sales, logistics, purchasing) or different GUI file for them, since each should be shown with different datas from the database.
This is perfectly possible. Each layout that you define within FMP is associated with a specific Table Occurrence. Once again, there really isn't much need for a separate GUI file for each layout, unless I'm missing something pretty drastic from your requirements.
3. I would like the tables in the database to be different (i.e. one table will hold all the product codes and its list prices, and another table will the product's selling prices) but I cannot figure out for the life of me how can I do this.
File>Manage Database> Select 'Tables' and off you go. Select 'Relationships' in the same interface to manage, well, relationships!
4. Account login and credentials to be created/managed in one of the filemaker's layouts, and not in the filemaker options. (I'd like to disable the user's access to all the functions above if possible, with custom menus) so ideally I would have another table which holds all the records of the accounts and its credentials.
This is possible, but there are some pretty strong reasons why you might want to avoid this from a security perspective, unless you have a real driving reason to do so. Have a look through this forum on some of the threads that cover this point.
Custom Menus are supported by Filemaker, and again, don't really need to be managed outside of the built in security functionality unless really needed.
Hope that helps, perhaps a little more detail on what you've got so far and where you want to be be might be helpful...
The reason why I'd like to separate my GUI from the database is because I am afraid that with the GUI that I am designing, the file maybe too large for the client to load each time off the server. Doing the separation will allow only the database to be loaded off the server, while having the GUI to be locally available to the client so that the time to load up will be much faster.
I have tried the relationship between tables but maybe I was doing it wrong all together. What I did was I created a table which held the records for product code and their respective list prices, and I have set an additional field to create the serial numbers each time a record is created (to make sure that each record is unique), then on another table I needed a field to calculate the sales price of the item based on some global field from a separate table which holds all the discounts and mark up rates.
What I am having the problem with this is that I just cannot figure out how can I link the sales price calculation table to the product code record table without telling it to create a unique record each time a record on the product code table is created. Perhaps you have a better way of solving this?
Have you got any metrics on 'the file may be too large to load each time off the server' ?
If you're creating a GUI / Front end file, and it's file size is too large to be delivered over the standard Filemaker network protocol, then I'd be tempted to say that you may want to re-design the GUI file.
Regardless, could you post an example of the file, or just a screen shot of what you've done in the relationship graph to give more detail on your relationship problem?
The client will cache the GUI. Using FileMakers File->Open Remote will work this way.
Whenever you make a layout change the client will need to re-download the GUI.
There are significant issues with a local UI / server data model. In addition to the "every client has to be patched" issue (which can be overcome), you also have to deal with the fact that, if there is no network connection, FileMaker will prompt the user to find the missing data file. Most users will simply point back to their local UI file (not knowing any better), which will break the data source relationship between the files.
Yes, you can enjoy some performance benefits from this model (not only does the UI have to load from the server, but all actions taken - layout navigation, scripts, etc. - have to interact with the server. As Carl mentioned, though, the UI file will be cached once the initial load is complete, so the performance benefits aren't as great as they first seem. And you have to deal with the other issues if you want to take this route. They're not trivial.
I agree with Mike et al when they say the client UI file + server data file is not a good choice for FM.
Filemaker is NOT your traditional development environment.
I can demonstrate how all of this works, the correct way to build it and you'll likely get some great ideas on what you may want. We've already done all of this with our Kosmas solution fully built in FileMaker using a data separated design. I'll pop the hood and show you how it's done. It includes every module you can think of and seamlessly allows each user to have a local file communicating with the server...even has auto-updates. Contact me via the DocuWrx website and I'll send you a GoToMeeting link to demonstrate if you're interested.
I also have a UI on laptop/iOS and DATA files on FMServer solution. It works well, however I cannot show, so contact Eric for a demo.