Search results

No. What you can do is create the h: drive mapping with full permissions (for the data entry people) and create the g: drive mapping with read-only permissions (for the people that only need read-only access). Not sure how Access will handle the .ldb-file in the read-only scenario, though:o.

Glad that helped, you almost had me stumped :D.

If you create a table link to the target database, it should prompt you for the password. After that, just INSERT INTO the linked table. Or run an Append Query, if you prefer :D.

I take it, then, that the passworded db is not an Access db?

I hope it will never need to be done. I hope that if it ever does need to be done, you are the one doing it. I was doing a rant here, but I deleted it in favor of something constructive :D. I think the whole thing can be done in one fairly elegant (but largish :p) query. I dont't know what the...

You can't unless you know the password. However, if you have a non-password-protected frontend that links to that password-protected database, you can copy the table links from the frontend (hell, you could get the password itself) into your own database.

Yeah, I have an idea but I don't like it :mad:. I just re-tested the example and it works fine. Does the JobDate field in the example display the correct weekday? Oh yeah, the idea was that somehow your system is convinced that Saturday is the first day of the week. This sWhere = " WHERE " &...

So, what is the date field here? is it the LOB or the SumOfExternalShrinkage? I've no idea what either means.

There's a space missing here . Looks alright now: INSERT INTO xxxxx ( Project, costType, jobCharge, ResourceDesc, [upper/lower], Cat, SumOfhours, SumOfcost, SumOfoverhead ) SELECT projectData.Project...

Hi X36, Have a look at the attached example. BTW that sWhere = " WHERE " & WeekdayName(Weekday(Me.ActiveControl)) & " = Yes "will only work on English Windows. Use something like this Select Case Weekday(Me.ActiveControl) Case 1 sWeekDayName = "Sunday" Case 2...

In short: they take less storage space and work faster when JOINing on them. Normalization theory does not concern itself about the actual implementation of the schema; it says nothing about the data itself, only about its organization. The table needs an extra field to make each row unique...

Too true. I'm relatively new to Access, having successfully avoided it for years :D in client-server-land and some things that would kill performance on "big" database-servers work amazingly well in Access (and vice-versa). It's a matter of trying what works and what doesn't. It can also help...

Table tblClientContact does not have a unique key.

The primary key for TableSale should be (Location, SaleID). The primary key for TableSaleDetail should be (Location, SaleID, ItemID). The TableSaleDetail.DetailID column would then be unnecessary. In short, as it is, the TableSaleDetail misses a Location column (I hope that's a LocationID;))...

Hi Olorin, some well-placed indexes can speed up your queries. Also, having the data in local tables in an .mdb file on your local drive can help if your network is a bit slow. I use this sometimes: Sub CopyLinkedTableToLocal() ' copies all linked tables to local tables with the same name...

Try this: SELECT Table1.id, Table1.Variable FROM Table1 LEFT JOIN Table2 ON Table1.id = Table2.id WHERE Table2.id IS NULLThis will give you all invalid variable values in Table1.

rabbie beat me to it, but here goes: Personally, I'd do without the Nz(blah,"N/A") because it forces the last two columns into string datatype. And BTW, your data is wrong :) the BalanceID sequence counts back as time progresses. I used this to get the previous mutation (I turned the...

A quick fix might be replacing the "" in that mind-boggling expression with a 0. I do agree with the previous replier, though. Having the database normalized will save you a lot of hassle in the long run. It all depends on how long the run is going to be :)