Deleted files from table

[Gina Whipp]

Okay, I am offically stumped as Access doesn't just delete records. My only
other thought is some kind of corruption.

 

[Lena]

This sounds like the file# creation button I was going to attempt on the
field, but was concerned, as stated in my reply to Gina, that this would just
be another form of autonumbering. Could you give me your DMax code so I can
compare it to make sure this is correct before I implement to the original
form for the records?

 

[Lena]

Okay, this is what I have done. I made a copy of the table (of course),
turned the autonumber off on the File# field, added another autonumber field
to verify "lost" records. The autonumber fields are indeed the problem
areas. Their records are now showing up correctly. I noticed there were
gaps in the autonumbering sequencing. Also, some of the record counts are
based on scheduling codes, which could have been changed after the reports
were run so the scheduling code counts would be obviously off. I believe we
have found the problem, I would like to try the DMax for their file# field to
see if this works for them rather than using the autonumber field, although I
have my reservations as this still seems to be an autonumbering code.

 

[aaron.kempf]

Gina;

you're not stumped.

you're just defending a database that sucks.

Is it even _POSSIBLE_ to prevent deletes in Access 2007?

I think that is an admission by Microsoft that it was always too buggy
for real world usage.
Any properly designed database should _NEVER_ allow _ANY_ deletes for
_ANY_ reason.

-Aaron

 

[Gina Whipp]

I have desire to clog up this poster or ANY poster messages with your trash
which seems to be your goal. Your reply indicates you did not even read the
entire post but that's okay, for you that's par for the case. Your job must
have been outsourced to an Access programmer which is why you are so bitter.

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II

Gina;

you're not stumped.

you're just defending a database that sucks.

Is it even _POSSIBLE_ to prevent deletes in Access 2007?
I think that is an admission by Microsoft that it was always too buggy
for real world usage.
Any properly designed database should _NEVER_ allow _ANY_ deletes for
_ANY_ reason.

-Aaron

 

[aaron.kempf]

I can thoroughly understand your _LAZINESS_.

Is that why you haven't graduated from the first grade of the database
world?

Honestly-- WTF is wrong with you?

Are you mentally retarded?

Why would you possibly give mis-information?

SQL Server is _THE_ reccomended best practice for working with MS
Access.

-Aaron

 

[aaron.kempf]

I have desire to clog up this poster or ANY poster messages with your trash
which seems to be your goal.  Your reply indicates you did not even readthe
entire post but that's okay, for you that's par for the case.  Your job must
have been outsourced to an Access programmer which is why you are so bitter.

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II


Gina;

you're not stumped.

you're just defending a database that sucks.

Is it even _POSSIBLE_ to prevent deletes in Access 2007?
I think that is an admission by Microsoft that it was always too buggy
for real world usage.
Any properly designed database should _NEVER_ allow _ANY_ deletes for
_ANY_ reason.

-Aaron





- Show quoted text -

 

[aaron.kempf]

I'm not bitter.

I eat Access-sluts like you for breakfast.

Access -- as a database-- sucks. It isn't reliable, scalable,
useful.. It isn't fast or free or easy.

Only people that are stuck in the 90s would use it for anything.

-Aaron

 

[aaron.kempf]

And again-- for the record-- I am an Access programmer.

I just have enough balls to realize that Access isn't a database.
Access is merely a front end to SQL Server.

-Aaron

 

[Bob Quintal]

m:

yes, I have seen Access randomly, incorrectly-- delete records

Hallucinating again, Aaron.
Go Away and take your meds.
Don't go away angry, just go away.

 

[Bob Quintal]

I apologize, I meant record. This database has really frazed my
nerves. The person using it has started creating her own queries,
reports, etc.

Please see my reply post regarding shared database. No she is not
working in the table. By the most part I have the table hidden to
avoid users keying data directly into the table and base
everything on forms. However, she does know how to bypass this
option to get to the tables. This is what she has used to search
for her lost records or to check the sequencing of the records.

No there are no referential integrity setups or cascading deletes
in the DB.
The autonumber field has been used to create file# for each
record. Because
there are one-to-many instances in the DB, but they are not
associated with the file# only by the client name and number,
which does not generate any other reports or forms, the database
is sort of a data storage of how many times a client needed
assistance.

I have offered to remove the autonumber field and reset a new one,
but then her records or hardcopy files would be off by one number.
Not sure what I can do for her at this point. My suggestion is
to move on and be very careful about using the table or actually
paying closer attention to possible deletion of records. Totally
stumped.

An autonumber field is not guaranteed to be consecutive, only that
all rows are unique.
For example, if a user starts to enter a new record, then cancels
the new record, the autonumber that was assigned is not reallocated.

 

[aaron.kempf]

In _ACCESS_ right? I'm not so sure that this is always the case in SQL
Server

-Aaron

 

[aaron.kempf]

I'm not going to go away.

I fight for the careers of every Access kid around here.

For christ sakes-- it's only that I care for you guys that I'm trying
to get you guys to grow

 

[James A. Fortune]

VBA Sean;

I can thoroughly understand your _LAZINESS_.

Is that why you haven't graduated from the first grade of the database
world?

Honestly-- WTF is wrong with you?

Are you mentally retarded?

Why would you possibly give mis-information?

SQL Server is _THE_ reccomended best practice for working with MS
Access.

-Aaron

Aaron,

You're totally wrong here. Access is kindergarten, not first grade!
Although in time you might be proven correct in assuming that a SQL
Server backend with Access as a front end will be the most preferred way
to use Access, many people are not yet in a position where SQL Server's
strengths outweigh their current needs enough to justify a move at this
time.

My personal opinion is that SQL Server itself is a baby database, that
the technology is ancient (SQL was developed by IBM and gained
prominence about 1980) and that it does a poor job of modeling reality
except for the simple business purposes at which it excels. The theory
is called Knowledge Representation (KR). Trust me when I say that SQL
only contains about a third of what's needed to model knowledge
correctly and efficiently. If you suggest to someone in the KR area
that SQL is good at representing knowledge you would be laughed to scorn
in a fashion that is similar to the scorn you have heaped on Jet. SQL
is woefully inadequate for KR.

Access is great for my simple business purposes. Language innovations
with SQL such as LINQ are helpful and welcome, but they still don't make
up for SQL's overall shortcomings. Some of the most prominent academic
institutions at the forefront of KR include the Massachusetts Institute
of Technology, Cambridge U., Rensselaer Polytech and Stanford U. The
theory behind SQL is relatively mature so I don't see SQL growing or
stretching into what it needs to become in order to become a vehicle for
KR. I.e., a new paradigm is needed. Proper KR is elegant beyond words
compared to the capabilities of SQL.

So, am I, like others being lazy in the fact that we use SQL at all?
Maybe. Is Access kindergarten and SQL first grade? Maybe. I certainly
hope that something better than SQL will come along soon and transform
our understanding of databases. You can resume your rant now.

James A. Fortune
(e-mail address removed)

 

[aaron.kempf]

I think that Linq is the biggest con in the world; personally.

I don't need

From
Select
Where.

I need

Select
From
Where.

I just think that SQL Server has a bright future- I mean; it is the
most popular database for enterprises.

And it's free.
And it's easier to use than Access.

there are _NO_ practical reasons to use MDB for anything.

And no-- I'm sure as heck not talkign about linked tables to SQL
Server.. Nor SQL Passthrough.
What a waste of time.

If I write a sproc and I want to pass in 2 parameters-- based on stuff
on a form.

Real quick-- how much code do I need in ADP?

How much code would I need in MDB?

I dont' think that attacking SQL Server makes any sense. SQL Server
is merely a 'better engine for data' than Access.

Access has no engine; you are literally stuck up a river-- without a
paddle- when things go wrong.

I think that the troubleshooting capabilities of SQL Server alone..
make it worthwhile to move-- whatever the cost.

But again-- I believe that dev in SQL Server is _CHEAPER_ than dev in
Access; because it is easier.. and more powerful.

 

[aaron.kempf]

btw; I use 'Analysis Services' for everything I do.

I think that MDX is 100 times better than SQL.. but that's a different
story entirely

-Aaron

 

[Lena]

DMax worked!!! One thing I noticed that the numbering in the record window
showed a different number from the number created as a file number (off by 7,
which was the number of records missing). We ran the reports and by golly,
they were correct!!

I would like to thank everyone for their input and in such a timely fashion.
Problem solved!!

 

[Bob Quintal]

m:

In _ACCESS_ right? I'm not so sure that this is always the case in
SQL Server

-Aaron

Access, and SQL server.

 

[James A. Fortune]

I think that Linq is the biggest con in the world; personally.

I don't need

From
Select
Where.

I need

Select
From
Where.

You think it's a con because the "From" comes first? What about
Intellisense for SQL? What don't you like about LINQ? Don't you write
code?

I just think that SQL Server has a bright future- I mean; it is the
most popular database for enterprises.

That may prove correct. I think that SQL Server's deficiencies will
eventually make it obsolete. Until something better comes along I agree
that its future is bright .

And it's free.

I agree that it's free until you reach a certain point. Then it gets
quite expensive. I appreciate that Microsoft made it easier to try out.
Are you sure you're not working for Microsoft's Marketing Dept. right now?

And it's easier to use than Access.

A backend in SQL Server looks a lot like a backend in Jet. You say
you're using forms? Are they easier to create with what you're using?
The Books On Line (BOL) information contains way more information than
is required to use Access. The information is presented in a way that
is reminiscent of reading a list of all the commands in BASIC. What
about tools for making the data available on a web site? That could be
a cogent argument in favor of SQL Server.

there are _NO_ practical reasons to use MDB for anything.

How about lots of code examples? How about no software installation
necessary? How about a click and drag backup? How about the time it
takes to get familiar with SQL Server?

And no-- I'm sure as heck not talkign about linked tables to SQL
Server.. Nor SQL Passthrough.
What a waste of time.

If I write a sproc and I want to pass in 2 parameters-- based on stuff
on a form.

Real quick-- how much code do I need in ADP?

Not any for the sproc itself.

How much code would I need in MDB?

Not any for the query itself.

I dont' think that attacking SQL Server makes any sense. SQL Server
is merely a 'better engine for data' than Access.

I agree that SQL Server is a better engine for data than Access -- by
design. SQL Server is merely what it is, and no more. I'm not
attacking SQL Server because I think Jet is better. Quite the contrary.
I'm attacking SQL Server because I believe that Jet and SQL Server,
which both rely on some form of SQL, are inadequate for most
non-business applications. I'm warning that putting too much faith in
SQL is not very wise given its limitations.

Access has no engine; you are literally stuck up a river-- without a
paddle- when things go wrong.

Access has an engine. It's just flaky at times .

I think that the troubleshooting capabilities of SQL Server alone..
make it worthwhile to move-- whatever the cost.

I've used SQL Server. There was very little troubleshooting involved.
What kind of troubleshooting capabilities did you require? I imagine
that to truly optimize an application where the data is housed in SQL
Server can require much effort and therefore a need for troubleshooting
capabilities. Also, the words "whatever the cost" are not part of the
vocabulary of any of my customers.

But again-- I believe that dev in SQL Server is _CHEAPER_ than dev in
Access; because it is easier.. and more powerful.

More powerful? Yes. Cheaper? Please explain how. Easier? More
powerful seldom equates to easier. A few more testimonials from Access
developers explaining how SQL Server has made their lives easier and how
non-Access tools make creating a better frontend so much easier might
help. If SQL Server development really is cheaper than development in
Access then my customers will be quite interested in switching.

James A. Fortune
(e-mail address removed)

 

[Tony Toews [MVP]]

I eat Access-**** like you for breakfast.

That term is extremely offensive. Please apologize.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/