stefansmith

Hi, I am hoping some kind individual may impart some advice on what hardware I should be considering for the following. The short version is this: I am in the process of building a FM solution (extensively to run under Go) for the industry I work in. It is an "OFFLINE" solution to be marketed by one of the leading suppliers in the industry in which I work. What I am constructing is something I have already done and have used in a live situation for 18 months with other companies. This solution is more generic and focused on our industry as a whole, rather than our particular working practices. The Server is best thought of like an "email server"......it is merely there to allow the transportation of data from iPad to iPad within each company using the software and service. There is ONE table only on the server side database, containing around 14 text fields. The synchronisation and data replication is handled by storing the tables and records in these text fields and reassembling as necessary on the device. We have 18 months of doing this on large data sets and it works very well. To emphasise - the server is doing nothing more than temporarily holding data until other devices connect and retrieve it! It does not process any data whatsoever. In essence, an UPLOAD consists of writing records; the DOWNLOAD is downloading to the device. I am using the data separation model for this approach so there is one dedicated interface file that opens the connection to the server and as soon as the upload/download is complete, the database closes and connection is terminated. The experience we have is for a mid-sized company....there will be potentially many users with far less data and some with larger data sets. Based on experience, most connections to the server during our "sync" process last between 15 and 20 seconds. The longest connection time we have seen for a large data set was just under 60 seconds. This data has been collected over 30,000 transactions. Potentially, once the solution is released and marketed, the number of users could reach 1000 or more. Deployment would be across several servers as the number of users grow. IF a server were to handle groups of 250 users what would be required? I am looking at MAC ONLY HARDWARE, not Windows. If we reached 250 users we would deploy a second server and so on. Clearly, 250 users are not going to connect all at once although in "theory" they could....the database on the server is about as minimal as you can get......literally just 14 text fields per record. No calculations and 1 plain vanilla layout. Can anyone recommend a suitable hardware configuration? The 18 months of experience we have shows a sync process is requested on average twice a day.....with most connections lasting no more than 20 seconds.....and we have yet to see one peak past 60 seconds. Any advice would be gratefully received ! Thanks in advance, Stefan

Yes, I did indeed. Alas, we only have one server so I tested the client and it was fine....so I thought. To upgrade I had to remove FM11 and install FM12...by which time a day later it was in a live environment with next to know users due to a holiday weekend. It would have been possible to back track with quite a bit of work to re-enter live data back into the FM11 solution, but I spent an entire weekend coding for the new features offered by FM12 that I had to make a decision....live with it or switch back. I have taken a punt to live with it....that may well bite me, I don't know yet. But the important thing is I was fundamentally stupid....just sharing my negative experiences so others don't follow in my foot steps!

I thought I would share some of my disastrous issues with FM12 --- some of these have not been discussed here. Fortunately, fm support now has copies of the solution I have which demonstrates a huge number of problems and have been quite good in their feedback to date. I have a solution that is quite complex in nature. It is hosted on a mac -- fm server 12. Accessing this remotely over the Internet under fm11 was no issue. On fm12 it's a disaster. And here is one example that will frighten some of you! The MANAGE DIALOG box --- under FM11 this would take around 2 to 3 seconds to open. Once opened you can scroll up and down the 427 layouts I have without a problem. Under FM12 it takes around 3 minutes for the dialog box to appear. As you attempt to scroll you hit the spinning wheel. It takes around 7 or more minutes to go from top to bottom! And it never stops "spinning" as if it does not load all the data in which it needs. It is unusable - period. Create a new script. Use the script step GO TO LAYOUT. Choose a layout! Same problem although the list appears more quickly. Use the search box to locate a layout. If I type the word "schedule" the letter s appears.....few seconds later the letter c......it can take up to 20 seconds for the one single word I have typed in to appear. Fortunately, having submitted a clone to FM, they acknowledge the problem and have been able to replicate it. Bottom line, however, is it is impossible for me to do anything to the database remotely. I have submitted to FM today in relation to FM12 Go a very long list of bugs --- documented and able to reproduce with ease --- and most are performance related. And if you have a lot of scripts ---- with remote access it's like wading through mud! The scroll bars are slow....everything is slow. Unfortunately, I am an idiot and upgraded our solution as soon as FM12 was released. You live and learn! Unfortunately, Fm11 - windows XP With Fm12 FileMaker have joined the likes of Microsoft when they released windows vista! It's that bad.... As for LIST view.......in our solution all I can say is you haven't seen anything yet!