Im new to access and have a question about tables... :confused:
Example:

-#- -List-- -Numbers- -Previous-
-1- -this1- ----5----
-2- -this2- ----5---- ----10----
-3- -this3- ----2---- ----7----
-4- -this4- ----1---- ----3----

Basically I want the "Previous" Field of "ROW 3" to display the sum of its "Numbers" field and the "Numbers" field of "ROW 2" above it. I also would like it to update the table in real time if possible.
Could someone walk me through this please?
Thx in advance,
JimSolo

In Access, we don't put in tables what can be calculated from other fields. You'll have to make it in the report itself using «Running sum». I suggest that you make a search for «Running sum» to get more informations.

Well the problem with that is I cant use a report because I want the information to be editable. I would like to use a form if possible.
Should I maybe try importing from Excel??? Basically I want to do all the stuff you can do in Excel, On a form in the database. I know its possible but I wouldnt even begin to know how to take numbers off an imported Excel file and manipulate them in access :/

Let me try and show you what I would like to do:

Background:
This project is for my business and deals with a customer/service schedule type database. Simple enough up to this point and I have had no trouble getting all that set up BUT... :cool:

I dont want to have to open a bajillion different applications to manage my business. If I could find a way to get a check register form/table into my database I would be happy. I have no clue how to import an excel file. theres got to be an easier way. :confused:

If I could find a way to get a check register form/table into my database I would be happy. I have no clue how to import an excel file. theres got to be an easier way. :confused:

You are looking at this from the wrong angle. The running balance in a check register is a CALCULATION. Calculated values are generally not stored. You can calculate the balance by summing the transactions.

Ok but I dont know coding so I have no clue how to do that...
I been trying a new aproach by doing two queries, One for deposits and one for withdraws. Then I tried putting
= [dep Query]![TransactionDeposit] - [wit Query]![TransactionWithdraw]
into the control source of my "Balance" text box on the form I would use to enter Transactions but all I got was this error under the Balance text box when I opened my New transaction form:
#Name?

Could you show me an example of that and how I could impliment it into a check register?

This really isn't a coding issue. Assuming your register has a field for deposits and withdrawals, you would add a column to your query like so:

NetAmount: [Amount] * IIF([TransType] = "Deposit", 1, -1)

Then just Sum that column.

Another trick I've used is to use an integer field to store the transaction type. I then setup a table like this:

TransTypeID...Transtype
1...................Credit
-1..................Debit

then I can just use:

NetAmount: [Amount] * [TransType]

I think part of my problem is im trying to store the balance on a table.
I was trying to make the form calculate the queries on credits/debits then post that number in the balance section of that row in the register table.
I guess i forgot to mention I was using a table as a register. :/
is this possible at all?

I think part of my problem is im trying to store the balance on a table.
I was trying to make the form calculate the queries on credits/debits then post that number in the balance section of that row in the register table.
I guess i forgot to mention I was using a table as a register. :/
is this possible at all?

No you didn't forget, but you seem to have ignored my first answer. Calculations are NOT stored. The balance can be calculated for display at any time. Storing calcs usually violates normalization rules as well as data integrity.

Look for a check register sample app. You should be able to find one either here or on Microsoft's site. Start with that and build on it.

I also told you, in my post, that calculated values aren't stored in the tables.
Two members told you the same thing. Why do you keep on trying to do it?
Why ask for answers if you don't even listen to them? We take some of our precious time to help you for free, to find out that you just don't care. If you don't know how to do a database at all, I strongly suggest you to read a good book or take a course. Or, even better, pay a database designer to do it for you.

Me and my friends from this forum would be glad to build it for you. That is our job! I just don't understand people who wants to do it by themselves. You don't buy a whole beef and cut it yourself. Do you? No, you pay a butcher to do it for you. You should think the same way about databases. We are the professionnals. Give us money and we'll do it for you, and you'll have a good database well designed that will not crash all the time.

I don't mind helping those who wants to learn it, but as I can see from your posts, you don't even know about normalisation, which is the most important thing about databases design, and one of the first thing you would have learn in a computer science class, and you already want to buid a database. You've got to learn about it before you can do it.
No rancor!

@Newman
This is the reason why I mostly just try and do things for my self.
WAAAH I wont pay you to do it for me. I like doing things for myself and learning on my own. I hate having to ask for help.
Im not here to prove anything to anyone or earn any kind of "Database monkey" name for myself. I just needed some help and this IS a forum. Excuse me for asking though. Maybe you should state in your index somewhere that "Noobs will be flamed!" So that way you dont have to deal with questions such as mine if its soooo much of a hastle for you.
You can take your "holier than thou" attitude and stick it up your ass because its wasted on me.
thanks and have a nice day.

@ScottGem

Look for a check register sample app. You should be able to find one either here or on Microsoft's site. Start with that and build on it.

Thats the first thing I did. I couldnt find anything remotly close enough for what I wanted to do.

I can see that my little problem is becoming too much of a "hassle without a paycheck" for everyone so maybe Ill go see if I can pick up a "Access for Dummies" at the local barnes and noble.
Thx for NOT being an Ahole about it though Scott. Its much appreciated.

While I think you caught Newman getting out of the wrong side of the bed this AM, I empathize and agree with his comments. We both told you that storing calculations was not correct design and you did seem to ignore that advice.

I'm going to excuse your rude response because it was partially provoked but if you want further help here it's not a good idea to bite the hand of the feeders.

I couldn't find a checkbook register sample after a brief search but I did find this that might help you:

http://www.rice.edu/it/help/documents/training_docs/protected/pc/pc28.pdf

I didn't mean to be rude with you and I apologize if I was.

All I wanted to say was that you should at least consider the answers given and that I suggest you buy a book or take a course in Access. You don't need to do the whole university classes, but at least learn a bit about it before attempting to build a database on your own. Normalisation is the more important thing about any kind of databases. You should not think about designing a database before you know about it.

Again, I'm sorry if my previous post was too rough on you, but it wasn't what I wanted it to be. I did say "No rancor!" at the end. I bet I should have used smileys too. Anyway, just look at my signature and you'll find out that I am on your side, not against you.

[quote]I want to do all the stuff you can do in Excel[\quote] - based on the discussion you've been having so far, I would like to suggest a little refocus. Relational databases are not spreadsheets. They may look like spreadsheets when you open a table in datasheet view, but that is the extent of the similarity. Spreadsheets are more intuitive to the untrained because they combine the presentation and data storage layers whereas in a database, these two things are totally separate. That is why the advice to not store calculated values is so firm.

It is very easy to add a calculated control that sums the transactions. Add a footer to the subform (you may need to increase the size of the subform to make it visible) and add a control with a ControlSource of:
=Sum(your field name)

Of course, if you have separate fields for debits and credits or your transaction amounts are not signed, the calculation will be more complex.