Union – too many fields!

A

a a r o n _ k e m p f

Jet is throwing a tissy fit because it SEES too many columns?

there really ARE NOT too many columns.. right?

Do we all agree on that-- that this dude doesn't physically have >255
columns-- but Access _THINKS_ that there are?

it's the classic 'too many fields' bug

In other words-- stop bullying people who speak the truth-- and move
to SQL Server
 
B

BruceM

Since your answers rarely have anything to do with the question I suppose it
is silly to ask if you read the postings before you reply, but the point was
that a hard drive can be filled up because of the amount of data being
stored, not because it is "buggy". That's why there was that part "because
it is too full".

What _EXACTLY_ are you trying to say?
Yes, if your hard drive is buggy-- time to get a new hard drive.

When your database is too buggy-- it is time to move to SQL Server

that's all I'm trying to say.

I don't hit limits in SQL Server.
SQL Server 2005 Express works great for some of my needs..

SQL Standard, SQL Enterprise for others.

If your harddrive randomly started filling up when you tried to use it
more than once at the same time-- yes I would throw it away.

-Aaron
 
A

a a r o n _ k e m p f

technically-- it sounds to me like he is hitting a 'too many fields'
bug in Jet.
it's only natural to want to move to a better platform.
 
P

Pete D.

If software works within its defined limits this isn't a bug. A bug is
something that doesn't work up to the cappacity advertised. For an example,
please see mirror.
technically-- it sounds to me like he is hitting a 'too many fields'
bug in Jet.
it's only natural to want to move to a better platform.
 
A

a a r o n _ k e m p f

a) this person isn't trying to display > 255 fields
b) jet has a problem calculating what to do with this many tables /
fields


it's really really really simple math.
If JET is too buggy for real world usage-- then it's best to move to
SQL Server / ADP.

If you're mad that ADP doesn't work against Oracle-- then right a
letter to MS and Oracle.

-aaron
 
B

BruceM

Since you would use twelve tables for twelve departments (and hope no
departments are added, I suppose), your approach to design may be suspect.
It is likely that the performance problems you have had with Jet are due to
design flaws. SQL Server may be better at hiding those, just as an oversize
vehicle may help protect you when poor driving skills get you into trouble,
but sooner or later you are likely to face a rollover.
SQL Server and the large vehicle both have their place, but neither is the
answer in every situation.

a) this person isn't trying to display > 255 fields
b) jet has a problem calculating what to do with this many tables /
fields


it's really really really simple math.
If JET is too buggy for real world usage-- then it's best to move to
SQL Server / ADP.

If you're mad that ADP doesn't work against Oracle-- then right a
letter to MS and Oracle.

-aaron
 
A

a a r o n _ k e m p f

dude you are so wrong.

I'm just saying that there is a time and a place for one to one
relationships in rdbms parlance.

no-- my Jet troubles don't come from bad design-- it's just not
reliable enough for a half dozen people to use on a regular basis.

and when I say 'half dozen' I really mean 2 or 3 really really heavy
users.

SQL Server is not an oversize vehicle. It is a lean mean database
machine.
There is no point to ever using Jet for anything-- it just needs 'too
much development' to get it setup correctly.

and it needs to much maintenance to keep running.

a single corruption problem ever is the threshold for determining
whether Jet is 'ready for enterprise'.

I've seen 50 jet corruptions in 15 years. Which is enough that 'any
sane person' would move to SQL Server.

-Aaron
 
B

BruceM

A time and a place, yes, but a field for each department is neither the time
nor the place for one-to-one. That example (separate department tables) is
the only instance I can recall of any insight into how you approach design,
so it is reasonable enough to suspect other such design flaws as the cause
of the difficulties you have had with Jet.
There is also a time and a place for SQL Server, but it will not correct
design shortcomings.

dude you are so wrong.

I'm just saying that there is a time and a place for one to one
relationships in rdbms parlance.

no-- my Jet troubles don't come from bad design-- it's just not
reliable enough for a half dozen people to use on a regular basis.

and when I say 'half dozen' I really mean 2 or 3 really really heavy
users.

SQL Server is not an oversize vehicle. It is a lean mean database
machine.
There is no point to ever using Jet for anything-- it just needs 'too
much development' to get it setup correctly.

and it needs to much maintenance to keep running.

a single corruption problem ever is the threshold for determining
whether Jet is 'ready for enterprise'.

I've seen 50 jet corruptions in 15 years. Which is enough that 'any
sane person' would move to SQL Server.

-Aaron
 
A

a a r o n _ k e m p f

I'm not saying that it's the best option for everyone.

but in general-- it makes a lot of sense to vertically partition data
into logical groups.
otherwise- you have empty fields

I've never had a design shortcoming with SQL Server.
but I have been through 100 Jet corruptions.

so which is more of a threat?

-Aaron
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top