Looking for a server build

**Warprosper** · 03-12-12, 04:47 PM

Do you use active directory?

Are you planning to implement the new server in addition to what you already have or looking for a single server to handle everything. If single server: You're going to have to do some research on domain replication, promotion, and demotion. Also you will most likely experience some network downtime with this...

**jmw_man** · 03-12-12, 05:03 PM

Originally Posted by Warprosper

Do you use active directory?

Are you planning to implement the new server in addition to what you already have or looking for a single server to handle everything. If single server: You're going to have to do some research on domain replication, promotion, and demotion. Also you will most likely experience some network downtime with this...

Yes

1, quite possibly 2. We briefly discussed this last week and it seems to make sense to have 2 servers because there is a whole area of files and their functionality to our day to day operations that really have no relation to the others; ie, data gathering, performance monitoring, status logs with time stamps, etc, .. versus the business side of things.

**Partyball** · 03-12-12, 05:03 PM

So, you are going to start from scratch basically? Do you have a dedicated IT staff/person? Are you it? How important is the data? How important is uptime during on-peak and off-peak hours? Is the internet traffic heavy? What type of security are you proposing? I could go on for a while. It might be worth while to have a consultant come in and design something based on your companies wants and needs.

**jmw_man** · 03-12-12, 05:05 PM

Originally Posted by Rad

I don't know much about your current setup... But we never use access for anything. It's not very efficient, doesn't scale, has security issues in most setups, and performance wise it totally sucks compared to mySQL, for example.

We've been playing around with this lately. It seems really nice so far... MongoDB

Isn't access just a shell or platform?

**jmw_man** · 03-12-12, 05:09 PM

Originally Posted by Partyball

So, you are going to start from scratch basically? Do you have a dedicated IT staff/person? Are you it? How important is the data? How important is uptime during on-peak and off-peak hours? Is the internet traffic heavy? What type of security are you proposing? I could go on for a while. It might be worth while to have a consultant come in and design something based on your companies wants and needs.

We will probably definitely consult with someone to design something. They (when I wasn't there) consulted with someone in the past but I don't think they were too happy with the results. I do however want to be able to understand the proposal made available by the IT company.

edit: and yes, from scratch. New building, clean slate, we want it done right. We don't have a dedicated "qualified" IT person, I am the unqualified. We are growing but we are still too small to be considering hiring someone of this nature. We have other hiring needs that need to be filled first.

**Partyball** · 03-12-12, 05:45 PM

Once there is a proposal made, post it up. I am sure there will be a few of us to look at and critique it. Building from sctrach could be a good thing or a very bad thing. Make sure you build something you will go into 5 years or more from now. Whoever designed our sever room didn't do that. Now, we are stuck finding solutions to fit everything in a small area and keep it all cool.

There maybe someone you can hire as an "off-site" IT person. Like someone that admins from home and comes in once a week/month or whatever. I know there are several people that do that kind of thing here.

**AetheLove** · 03-12-12, 08:11 PM

Originally Posted by jmw_man

What are the downfalls to using Access? Is there an alternative?
I'll have to research ways to optimize file storage and learn how to implement an effective document cache.

The last time I had anything to do with Access, it was a reasonable way for someone to mock up a quick-and-dirty relational database at their desktop. As soon as more than one person wanted to use it, it quickly became clumsy. In my (narrow) experience, most people used it because it's what was available in the sense that they already had client licenses or a site-license (anyone who had a desk and a chair had MS Office). It was slow, and as it grew bigger or more complex it quickly got creaky. In a Microsoft shop, "real" relational database stuff involved extra money on the server side, and extra money per-client.

I attribute the spectacular success of MySQL (and Postgres, and a few others) to insanely expensive and bad products from MS.

That said, I have no idea what's happened to Access. I haven't had anything to do with it for a decade. Maybe it's a decent product now, and maybe it's up to the task. I really couldn't say.

I don't have a really good handle on what your business does, but I will say that I've run across plenty of instances where someone in an office is using a small DB to do something that could be done better without a DB. Most data that people use just isn't that complicated. Most of the data we come across regularly is either a List, or simple two-dimensional data (rows and columns, a spreadsheet). If you store a complex archive of documents and need to do SQL queries to retrieve them, then a DB is useful. Otherwise, a file system may be all the DB you need.

Pontificating aside, if there's an industry-standard, or vendor-recommended way of doing what you do, then that's often the easiest.

Originally Posted by jmw_man

8GB, doesn't sound like much to me considering there are servers out there running 128GB.... What do you mean by "filling up" and "swapping"?

Most computers are set up so that if they are using all the space in their RAM, they swap some of what they have in RAM onto disc (into the swap space) to sort of hold it off-to-the-side so they can move the new data they need into RAM. Then, whenever they have to do that thing they swapped out, they swap it back in again by moving out some other chunk of data in RAM onto disc and moving the first bit back. It's nice that they can do this, but it's super slow. RAM is very cheap now, so if you're swapping a lot (or even at all) then get more. A nightmare scenario would be if you've got a server with 8 gig of RAM and are working on a 24 Gig database, then you will be swapping pretty much continuously.

But that's just one way things can go wrong. Maybe that's not the problem at all. If you're serious about Doing It Right, you really need to get someone on-site that knows what they're doing. Depending on where you are, finding such a person might not be easy.

Trying to get a handle on what the problem is before you find someone (ie: what you're doing now) is a good thing.

Cheers,

AetheLove

**kibner** · 03-13-12, 06:58 AM

I agree with everyone suggesting to hire a a consultant to help you out.

At work, we tend to use Access as a front end to either an Access database on normal network storage (for 1-3 users) or as the front end to a MSSQL database on one of our clustered VM servers. Access works great as a front end because it is easy to create gui that users are already familiar with.

Sent from my DROID3 using Tapatalk

**Warprosper** · 03-13-12, 07:14 AM

This server for example.... we use for document referencing....aka paperless records system. We have approximately 150-200 concurrent users feeding documents into this server. So in regards to your needs...I would suggest something about 1/3 to 1/2 the size and power of this one.

**jmw_man** · 03-20-12, 10:55 AM

Originally Posted by AetheLove

The last time I had anything to do with Access, it was a reasonable way for someone to mock up a quick-and-dirty relational database at their desktop. As soon as more than one person wanted to use it, it quickly became clumsy. In my (narrow) experience, most people used it because it's what was available in the sense that they already had client licenses or a site-license (anyone who had a desk and a chair had MS Office). It was slow, and as it grew bigger or more complex it quickly got creaky. In a Microsoft shop, "real" relational database stuff involved extra money on the server side, and extra money per-client.

I attribute the spectacular success of MySQL (and Postgres, and a few others) to insanely expensive and bad products from MS.

That said, I have no idea what's happened to Access. I haven't had anything to do with it for a decade. Maybe it's a decent product now, and maybe it's up to the task. I really couldn't say.

I don't have a really good handle on what your business does, but I will say that I've run across plenty of instances where someone in an office is using a small DB to do something that could be done better without a DB. Most data that people use just isn't that complicated. Most of the data we come across regularly is either a List, or simple two-dimensional data (rows and columns, a spreadsheet). If you store a complex archive of documents and need to do SQL queries to retrieve them, then a DB is useful. Otherwise, a file system may be all the DB you need.

Pontificating aside, if there's an industry-standard, or vendor-recommended way of doing what you do, then that's often the easiest.

Cheers,

AetheLove

Response from the Operations Manager on Access:
(WES = Wells Enterprise Solution)

"WES is a database built in Access. Access is a complete container. You build tables to organize and store data. Then you can build queries, forms, reports, macros and do full VB coding to build complete software applications. Access can be both a back end and front end. Right now I have WES broken into 2. 'Wells Manufacturing Database Master' is the file on the server and this file only contains the tables with our data. It is currently around 36-40 MB, it really isn't that big. The front end part, 'WES', is installed locally on everyone's machine. The front end accesses the back end by use of linked tables which are linked to the database on the server. If the computer isn't connected to the share drive where the tables are linked to, you will get an error message when you open WES.

ACCESS can be setup as crudely and simply as you want, or it can be very complicated and extensive and as powerful as any software available. Access is good when you have a limited users, generally only 3-5 simultaneously, as you start to need true client/server applications with many users with a high chance that they will be accessing the same records at the same time frequently then Access starts to become less of a good choice. most programmers prefer to build the front end using VB.net and they will access the data using many different database options, they may start out using Access as the back end and later it can be upgraded to SQL server.

For our purpose we will be upgrading our database a little at a time. Some parts of the database will only be accessed by 1-2 people and this will never change. Other parts may start getting accessed very frequently and by the whole shop. For these new systems I am putting together separate ACCESS front ends which only connect to the back end for data access and then disconnect once the data is obtained. Later on we could always build the front end somewhere else. For now I prefer to use Access, I can do all the things that many programmer gripe that they can't do and I can do it way faster than I could using Visual Studio. Now it has been 10 years since I have used Visual Studio and I am sure the new releases are much easier to use. The one thing that I like about access is that you can setup forms very quickly and you just drag and drop the fields on the form. In Visual Studio you have to write the code which populates all of the fields and this takes more time, although I know they were working on some of this 10 yrs ago, it's very possible that they have made it a lot easier and cut down on a lot of the coding time.

The good thing is that all of the microsoft products are compatible with each other and the VB is pretty much the same across the board. So it is very easy to integrate all of these solutions together and having bits and pieces really isn't a problem. Our solutions will involve Access, SQL Server, Excel, Outlook, Adobe (pdf) & many more."