>>55070490
Tell them you know how to use odbc connections with it.

>>55070490

What exactly do you want to know, OP?

Access uses a T-SQL dialect (it's 90% overlap with T-SQL), which means you can use SQL with some nice functions on top..

>SELECT [field nr. 1] AS f1, Nz( [field nr. 2], 0) AS f2, Iif([field nr. 1] = 3, 4, [field nr. 1]) AS f3

This gives you three fields:
-[field nr. 1] gets renamed as "f1"
-[field nr. 2] gets renamed as "f2", if contains a NULL value, it returns "0" (instad of NULL), the "non-zero" function is really neat..
-[field nr. 3] gets renamed as "f3", if it contains "3" it returns "4", otherwise it returns it's original value


Access has a build-in GUI-System with Forms and Queries. But be aware that you can have conflicts:
In access there is more than one way to do it:

Either using "automated" queries to populate the form, change values and so on.
Or using VBA (Visual Basic for Applications) wich gives you the complete power of managing Access and even Win APIs (if you want to).


This means you can either store queries as objects (makes sense if the customer wants to wknow what happens) or hide it in the VBA code (makes sense if it's a complicated query you build).


With VBA you can also controll the whole MS Office package:
You press one button, Access opens Excel, reads the entries, opens Outlook, sends mails and closes Excel and Outlook, opens PowerPoint and puts a graph of the mails you send on it... You name it.

Therefore, a good introduction to VBA is using the Excel Macro recorder.

But be aware that each Office product has it's own data modell:

ThisWorkbook.Sheets("Sheet 1").Cells("A2") makes only sense in Excel.
DoCmd.RunSQL "DELETE FROM Table" makes only sense in Access.


Oh yeah, also Access has basically two dataset modells: DAO and ADO.


Read up about the differnces..
DAO is better for everything within Access, ADO has some advantages when you split your DB in frontend and Backend.. but it's a little bit more complicated.

Of course you can also use ODBC and other connections..

>>55071844
I>>55071844
m pretty familiar with queries and forms etc. Havent used SQL though.
Im just not sure what else i should educate myself on. The job description requires me to "assist in enhancing existing databases through specified improvements and updating them regularly."

>>55072161

>assist in enhancing existing databases through specified improvements and updating them regularly.

It could mean anything..
Maybe they want to insert some new fields into existing tables? Who knows..

Access is used by a lot of people. Some have no idea about databases and think it's a "bigger version of Excel". And some use it as normalized multi user Frontend-Backend Solution with local Intranet access.

Of course you don't play in the same league as an Oracle DB or MS SQL Server, but you also can do complicated stuff with it.


So just relax and see what they want you to do.

And try to get into SQL and VBA as it makes you life a lot easier. The "Query architect" of Access is OK for a lot of stuff and will carry you far, but eventually you might encouter problems that you better solve in SQL.


Personally I think it's easier to use Forms as a simple GUI and do everything behind the scenes with VBA. Some people prefer using the forms as real forms though, binding text field to dataset fields and binding a recordset to a form. But I don't like this approach, it's starts to get messy very soon becase you don't know what happens at which place..

Whatever you do, mixing programming and "automated form properties" is a bad idea. You should stay with one.

>>55072383
Yea it is quite vague what they are after. I'll look into using SQL and VBA. Thanks for the detailed replies