Hardware needed??

I'm currently running a msde 2.8 server on a pentium 4 2.4 with 512 megs of memory and it is slow for client computers. What would you suggest for a server Memory, processor, mirror hard drives?

The software I am running is a Point of sale software package. The server is currently running on one of the registers and I'm plan on installing a back office server. Any advise would help greatly.All you can get?

Without knowing a LOT more about what you are doing, what problems you've had, what you want to add, etc, we're pretty hard pressed to give you simple answers!

-PatP|||The current problems that I am having is. When a item is scanned it takes 30 seconds to come back with a product. I am wanting to run a windows 2003 server running msde and in the future switch it to sql 2005. My database is around 130 megs and growing. In 2 years it will be around 1gig or larger. I have 2 clients currently but may grow up to 5 clients.|||Typically the fetch of an SKU (roughly the same thing as what you are doing) takes about 275 ms using a full blown copy of SQL Server. It shouldn't be a bunch slower for MSDE unless you are running into connection throttling somehow (MSDE only permits at most 5 running threads at one time).

Are you certain that the delay is really happening inside MSDE, and not somewhere else in your system?

-PatP|||All you can get?

Without knowing a LOT more about what you are doing, what problems you've had, what you want to add, etc, we're pretty hard pressed to give you simple answers!

-PatP

That never stopped us before...

Let's see...the database is 130mb...you have 512mb...

I would say the whole damn thing is in memory...

SO...if you eliminate the fact that there's probably no I/O, AND I'm assuming that the thing is indexed properly....

I'd go with the thought that the code sucks...

oh...hold on...what else is running on the box?|||There is nothing else running on the system. The point of sale software is also running on the machine. I would like to adventually have that machine act as a virus server.|||Poke around in the Task Manager a bit. See if anything there attracts your attention. Be sure to check to see how much memory various processes are using, how much memory the machine has used, and how busy the CPU is.

Are you familiar with Performance Monitor? It can help a bunch trying to diagnose this kind of problem.

-PatP|||SQLserver uses 150 - 200 megs of memory. Not much cpu usage.|||If that is the case, it looks like SQL Server isn't your culprit. If it was, the CPU would be higher (for CPU bound tasks), or both the CPU and the RAM would be higher (for disk bound tasks).

My guess is that the problem lies either in the application itself, the network (especially likely if modems or wireless is involved), or on the client machine.

We still haven't nailed down the culprit, but I don't think that MSDE is your weak link in this case.

-PatP|||Well I just tested it by scanning some items. It uses about 30%-70% of the processor. This is running on a windows 2003 with sql server 2000. The hardware is a xeon 2.4 512 megs of memory. This machine is very effecient and works like a wal-mart. It comes up as fast as you can scan. But uses a lot of the processor. My other sites like I said our pentium 4 with 512 running xp pro and msde 2.8.

Thanks for all the help so far|||So the question is what should I roll out for a server to replace the desktop p4 machines? Also is there something I should be looking at in sql itself? The % of processor was with only 2 machines scanning items which is not very uncommon.|||The biggest problem is that MSDE is intended to be a run-time package for applications developed with Microsoft Visual Studio. You are sorely hampered trying to figure out what your performance problem is due to an almost total lack of tools.

The official gospel from Microsoft is that you need to report the problem to your application vendor, and have them either re-tune your database for you or sell/re-sell you the tools to allow you to tune it yourself. Once you get a full copy of SQL Server (even the BackOffice version which is somewhat limited compared to the full-featured versions), you'll be much better equipped to deal with this kind of problem.

Right now you are kind of like the merchant that buys a vending machine that is serviced by the seller... You have no keys, no tools, no access to the inside of the machine, and all you can do is report malfunctions to your vendor... A nice, simple, black-box arrangement where you can't monkey with things even should you want to!

-PatP|||REally?

With that said, I wonder how many developers deploy this solution...

I was just starting to head down this path as well...

What about MS Access and MSDE?|||MSDE gives the end user OSQL.EXE and BCP.EXE, but not much more... No Enterprise Mangler, no Query Analyzer, no Profiler. This is plenty for the folks who want a "data appliance", but doesn't give you much in the way of tuning tools.

I'm pretty sure that the Developer Edition of MS-Access allows run-time distribution of MSDE, but I haven't checked the licensing on it lately.

-PatP|||a 130MB database.. is much of it in only a few tables? I'm wondering if it really is indexed properly.. A product lookup is basically just a 'select' query right? maybe a few joins or such..

Also, there are some free management utilities for people without enterprise manager.
Check out http://www.aspfaq.com/show.asp?id=2442
Some cost money, but not nearly as much as any real version of sql server.|||It is only a simple query. SKU, Product description, and In store upc. I just don't understand why my processor on my servers are hit so hard

Hacking around with a prototype

DO NOT say "Visio".
This is not for a client project of any kind. I just want to experiment.
If my experiment is successful, or leads me in a direction that whaps me on
the head and says, "SQL Server", then it will go into SQL Server.
Otherwise, I will build the thing in Access. WHY? Because it's easier to
slap something together in Access. And even if the experiment succeeds, and
goes into "production", it will only be for only my personal use.
So, I am asking for opinions: SQL Server with a .NET front end? or SQL
Server with an Access adp front end? Or just all in Access?
Please state your opinions for each technology, along with two paragraphs of
WHY you choose that technology.
Remember, this is not for work, or for a client. But it will accumulate
real data.
--
Peace & happy computing,
Mike Labosh, MCSD MCT
Owner, vbSensei.Com
"Escriba coda ergo sum." -- vbSensei"Mike Labosh" <mlabosh_at_hotmail.com> wrote in message
news:u4kcQu0jGHA.4660@.TK2MSFTNGP03.phx.gbl...
> DO NOT say "Visio".
> This is not for a client project of any kind. I just want to experiment.
> If my experiment is successful, or leads me in a direction that whaps me
> on the head and says, "SQL Server", then it will go into SQL Server.
> Otherwise, I will build the thing in Access. WHY? Because it's easier to
> slap something together in Access. And even if the experiment succeeds,
> and goes into "production", it will only be for only my personal use.
> So, I am asking for opinions: SQL Server with a .NET front end? or SQL
> Server with an Access adp front end? Or just all in Access?
> Please state your opinions for each technology, along with two paragraphs
> of WHY you choose that technology.
> Remember, this is not for work, or for a client. But it will accumulate
> real data.
> --
>
SQL Server with a .NET front end. SQL Server 2005 with .NET 2.0 Winforms
beats Access across the board. With data binding and Visual Studio
integration, you have a development environment that is as easy to use as
Access, but without the limitations, without VB Script, etc. Also you
should invest your time in technologies that are strategic to your career
and understanding. Your deep and intimate knoledge of Access ADP projects
is unlikely to come in handy later. And you should prototype projects and
do little projects in big technologies. 100% of the code and skills you use
in a .NET 2.0 Winforms, SQL Server implementation are applicable to "real"
projects.
David|||On Tue, 13 Jun 2006 20:43:31 -0400, "Mike Labosh"
<mlabosh_at_hotmail.com> wrote:

>So, I am asking for opinions: SQL Server with a .NET front end? or SQL
>Server with an Access adp front end? Or just all in Access?
Or my choice for such projects, SQL/Server for data storage and an
Access database (NOT an adp) frontend. Just another option for your
mix...
John W. Vinson[MVP]|||> SQL Server with a .NET front end. SQL Server 2005 with .NET 2.0 Winforms
> beats Access across the board. With data binding and Visual Studio
> integration, you have a development environment that is as easy to use as
> Access, but without the limitations, without VB Script, etc. Also you
> should invest your time in technologies that are strategic to your career
> and understanding. Your deep and intimate knoledge of Access ADP projects
> is unlikely to come in handy later. And you should prototype projects and
> do little projects in big technologies. 100% of the code and skills you
> use in a .NET 2.0 Winforms, SQL Server implementation are applicable to
> "real" projects.
> David
If you are the "David" that I think you are, then you should already know
that I am a badass at Access, SQL Server and .NET.
That aside,
I take issue on your thoughts about data binding. The way Access does
databinding is sweet and free. The way Visual Studio.NET does databinding
is expensive, braindead, sloppy, retarded and dangerous. vbSensei will
*never* use data binding in .NET. It is idiotic at best, satanic and
abyssmal at worst. I prefer a .sln solution with either a WIN32 or Web App
against a Database project, all inside the same solution, but at this point
in the design phase, seems a bit much.
What I mean is, that while "real architects" design a system with Visio, I
as a developer am in easier territory with the cheesy way Access does
things, just so I can drag-n-drop something together to prove if it will
work. (No offence to you Access folks)
Perhaps I did not phrase my question clearly enough: I want to prototype a
system that will not be largely scaled. Its purpose is for my wife (the
*totally* non-tech user) to be able to click some buttons when someone calls
her on the phone -- , say, I'm out teaching a class, and in the mean time
some MCT broker calls her on the phone and asks, "Can Mike do the xyz
class?" She should be able to click a combo box or button and figure it
out, and then say, "Nope he's booked all up", or, "Yeah, hea's available on
the w of abc". So the thing will only be used by one (perhaps two)
persons.
I could do this in Access. I am just asking for design opinions. Maybe
from people that have done this before.
My own gut instinct as a middle-tier developer is that this should be
implemented as an SQL Server database with MTS / COM+ EnterpriseServices
components that feed a web page....... but the practical person in me
says, "Dude, that's stupid. You have two users, for crying out loud!"
Peace & happy computing,
Mike Labosh, MCSD MCT
Owner, vbSensei.Com
"Escriba coda ergo sum." -- vbSensei
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O4ejo30jGHA.4816@.TK2MSFTNGP04.phx.gbl...
> "Mike Labosh" <mlabosh_at_hotmail.com> wrote in message
> news:u4kcQu0jGHA.4660@.TK2MSFTNGP03.phx.gbl...
>|||> Or my choice for such projects, SQL/Server for data storage and an
> Access database (NOT an adp) frontend. Just another option for your
> mix...
Thank you so much for your inclusion of another exponent inside my design
matrix.
GRBNF!
I will be assured to help the people in your group with the most bizarrely
abstract code snips the world has ever seen.
J/K
But thanks for your input. I will now return to my glass of wine [DAMN
WAIT! SPILLAGE!] and another napkin with a pen. :)
--
Peace & happy computing,
Mike Labosh, MCSD MCT
Owner, vbSensei.Com
"Escriba coda ergo sum." -- vbSensei|||"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote:

>SQL Server with a .NET front end. SQL Server 2005 with .NET 2.0 Winforms
>beats Access across the board. With data binding and Visual Studio
>integration, you have a development environment that is as easy to use as
>Access,
How is Net 2.0 Winforms as easy to use as Access?

>but without the limitations, without VB Script, etc.
What limitations? Especially that are applicable for one user or
even less than, say, 25 or 50 users?
VB Script? I was unaware that Access used VB Script?

>so you
>should invest your time in technologies that are strategic to your career
>and understanding. Your deep and intimate knoledge of Access ADP projects
>is unlikely to come in handy later. And you should prototype projects and
>do little projects in big technologies. 100% of the code and skills you us
e
>in a .NET 2.0 Winforms, SQL Server implementation are applicable to "real"
>projects.
<snort> Every w or two I turn down emailed requests for me to work
in Access. I guess I'm just not doing real work.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm|||"Mike Labosh" <mlabosh_at_hotmail.com> wrote:

>Perhaps I did not phrase my question clearly enough: I want to prototype a
>system that will not be largely scaled. Its purpose is for my wife (the
>*totally* non-tech user) to be able to click some buttons when someone call
s
>her on the phone -- , say, I'm out teaching a class, and in the mean time
>some MCT broker calls her on the phone and asks, "Can Mike do the xyz
>class?" She should be able to click a combo box or button and figure it
>out, and then say, "Nope he's booked all up", or, "Yeah, hea's available on
>the w of abc". So the thing will only be used by one (perhaps two)
>persons.
>I could do this in Access. I am just asking for design opinions. Maybe
>from people that have done this before.
>My own gut instinct as a middle-tier developer is that this should be
>implemented as an SQL Server database with MTS / COM+ EnterpriseServices
>components that feed a web page....... but the practical person in me
>says, "Dude, that's stupid. You have two users, for crying out loud!"
<shrug> I have a client with 25 users in Access all day long. It
works and works well.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm|||"Mike Labosh" <mlabosh_at_hotmail.com> wrote in message
news:u4kcQu0jGHA.4660@.TK2MSFTNGP03.phx.gbl...
> DO NOT say "Visio".
> This is not for a client project of any kind. I just want to experiment.
> If my experiment is successful, or leads me in a direction that whaps me
> on the head and says, "SQL Server", then it will go into SQL Server.
> Otherwise, I will build the thing in Access. WHY? Because it's easier to
> slap something together in Access. And even if the experiment succeeds,
> and goes into "production", it will only be for only my personal use.
> So, I am asking for opinions: SQL Server with a .NET front end? or SQL
> Server with an Access adp front end? Or just all in Access?
> Please state your opinions for each technology, along with two paragraphs
> of WHY you choose that technology.
> Remember, this is not for work, or for a client. But it will accumulate
> real data.
> --
>
> Peace & happy computing,
> Mike Labosh, MCSD MCT
> Owner, vbSensei.Com
> "Escriba coda ergo sum." -- vbSensei
>
Options =
1. SQL Server back end and .Net front end -- why? Seems to be overkill.
2. SQL Server back end and Access mdb front end -- given your level of
expertise could be blown off pretty quickly, probably almost as quickly as
option 4
3. SQL Server and Access adp -- hesitant to go this way because of
discontinuation of MS support/recommendation for adp's.
4. Jet and Access mdb -- given your level of expertise could be blown off
pretty quickly using a single mdb and then splitting into FE and BE when
done.
Usage = Single user
Assumption: Database will be split into a front and a back end if using Jet
and SQL Server.
Given above: There is a relatively low risk of database corruption if using
Jet.
If even this low risk of database corruption with JET is unacceptable then
use a SQL or MSDE backend.
If for some reason the design of the application would benefit from triggers
and stored procedures (I would assume from the limited information given
that this is not critical) then use SQL or MSDE backend
If the physical size of the database is too much for Jet or MSDE (again
given the information I am assuming this is not the case) then use SQL
Server backend.
Given your level of Access and SQL Server expertise, the choices seem to be
Jet and Access or SQL Server/MSDE and Access mdb. with the choice really
resting on answers to:
1. Can you live with the possibility of corruption if you use Jet. Chances
are this is a minimal risk given the usage.
2. Usefulness that triggers and stored procedures might give you development
using SQL/MSDE backend. Again, given the usage these are probably not that
critical.
3. Physical quantity of data. Will probably be OK with Jet or MSDE.
Final Answer: Jet and Access.|||>>> try to use telnet
"Mike Labosh" wrote:

> DO NOT say "Visio".
> This is not for a client project of any kind. I just want to experiment.
> If my experiment is successful, or leads me in a direction that whaps me o
n
> the head and says, "SQL Server", then it will go into SQL Server.
> Otherwise, I will build the thing in Access. WHY? Because it's easier to
> slap something together in Access. And even if the experiment succeeds, a
nd
> goes into "production", it will only be for only my personal use.
> So, I am asking for opinions: SQL Server with a .NET front end? or SQL
> Server with an Access adp front end? Or just all in Access?
> Please state your opinions for each technology, along with two paragraphs
of
> WHY you choose that technology.
> Remember, this is not for work, or for a client. But it will accumulate
> real data.
> --
>
> Peace & happy computing,
> Mike Labosh, MCSD MCT
> Owner, vbSensei.Com
> "Escriba coda ergo sum." -- vbSensei
>
>|||try to link you project to telnet we already try it but dont try it if you
have an existing law in hacking, coz we do not have a law.
"jetro=)" wrote:
> "Mike Labosh" wrote:
>