Add data to combobox recordsource (1 Viewer)

[Pat Hartman]

It is a HUGE lesson. It probably took me 5 years to learn some of that stuff. Just having someone hit me in the head with - the event procedures are "hooks" off the main line of the form object - would have catapulted me into a better understanding of event procedures earlier.

Splitting the FE and BE came to me immediately because my first Access databases had DB2 BE's so I never had embedded tables until much later. So, by the time I got to a client where I was going to create Access (Jet/ACE) BE's, I already understood why I didn't want embedded tables.

VBA is a pretty simple language. If you already know SQL, then you are very far along the learning curve. You just need to understand "the Access way". Start with taking your hands off the keyboard any time you decide you need to code your way out of a problem and think - did those fabulous Access developers in 1991, think about this? The answer is pretty likely - yes. So, look for a setting to help or a function. Make sure you review the list of VBA Functions. Keep a link to the web page of VBA functions by category. Having to search the alpha list is not helpful. If you need a function that works with dates, you will find it in the date category. You probably won't need to write code at all. If there is no property and there is no function, then try a query. Your final and LAST option is code, don't make it your first I've written my million lines of code and I don't need the practice.

 

[jpl458]

It is a HUGE lesson. It probably took me 5 years to learn some of that stuff. Just having someone hit me in the head with - the event procedures are "hooks" off the main line of the form object - would have catapulted me into a better understanding of event procedures earlier.

Splitting the FE and BE came to me immediately because my first Access databases had DB2 BE's so I never had embedded tables until much later. So, by the time I got to a client where I was going to create Access (Jet/ACE) BE's, I already understood why I didn't want embedded tables.

VBA is a pretty simple language. If you already know SQL, then you are very far along the learning curve. You just need to understand "the Access way". Start with taking your hands off the keyboard any time you decide you need to code your way out of a problem and think - did those fabulous Access developers in 1991, think about this? The answer is pretty likely - yes. So, look for a setting to help or a function. Make sure you review the list of VBA Functions. Keep a link to the web page of VBA functions by category. Having to search the alpha list is not helpful. If you need a function that works with dates, you will find it in the date category. You probably won't need to write code at all. If there is no property and there is no function, then try a query. Your final and LAST option is code, don't make it your first I've written my million lines of code and I don't need the practice.

The VBA functions by category is now bookmarked. Speaking of errors, I once wrote a service charge routine for a bank, and forgot that load halfword (360 Assembler) drops the sign. I closed around 400 bank accounts, and the next day the customers were lined out down the street. But through experience I learned that you never write code till you run it frequently in your head. I did some of my best coding and design work while I was driving. One morning I drove about 5 miles past my place of employment till I realized where I was. But the routine worked, once I got to work.
Last point, in 360 Assembler there were 24 instructions, and you carried everything you needed to know about the language on a green card, that ended up with a lot a notes scribbled in the margins. If you lost your card it was like losing a part of your brain. Now there are statements, which remind me of the German language, where you can have 1 word that really is the packaging 5 other words. Whole sentences can be expressed in one word. ACCESS reminds me of that.

 

[Pat Hartman]

I can relate to that. My first language was machine language for the 1620. I never actually worked in that language but it did get me my first job where my employer sent me to school for 3 months to learn COBOL and JCL. Later, in order to take the advanced COBOL course, i had to take the 360 Assembler language course. I had spent so much time before then with core dumps and reading the BAL generated by the COBOL compiler that all of my BAL programs looked like they were generated by the COBOL compiler rather than written by a BAL programmer

It is always better to test before putting some new code into production. One of my clients had EIGHT, count 'em EIGHT staging environments. Code moved through and was tested in each one. Very little bad code ever made it to production which was good because no one wants to see helicopters dropping like flies especially if it is Marine 1. But I guess it depends on your opinion of the occupant
To be clear, I didn't actually write code that ran the helicopters although my husband did. But, I still had to get my code through eight levels anyway even though it was mostly inventory control or general ledger.

 

[jpl458]

Later in my career,I worked for company that made massively parallel, relational database back-end computers. When I was in L.A, I would spend time with the developers and watched the never-ending process of regression testing of new software. I spent a lot of money on beer for those people. Me and my people sold and installed one that was 400 refrigerator sized cabinets. It was 1 gig of disk per cabinet. The PC I am writing this on dwarfs that machine. That deal went down in 1989. I watched the industry go from data PROCESSING to DATA processing, especially with the advent of relational DBs.

I will leave you with a puzzle. Assembler folk are fond of puzzles when they involve BAL. I remember one day a guy said the he could round a dollar and cent value to the nearest nickel, and do it in 6 instructions. Everyone in the pool dropped what they were doing and feverishly tried to do it in 5 instructions. (That was when everything was expensive, memory, disk, computer time.)

So here is the question. I have 2 fields, A and B, of any type, and I can swap the values of those 2 fields in 3 instruction, and not use a 3rd field. We actually used this when writing in physical I/O that required double buffering because the disks were too slow.

Pat, it's been a real treat chatting with you.

 

[jpl458]

Just did a bit of tinkering and the answer to the puzzle I think will work in VBA as well.