Search results

@Pat Hartman Pretty much what I said, or meant to say.... When using #10/15/2020# in anything that is access (that means anything sql like, including domain functions) you need to format it MM/DD/YYYY. I.e. ... where SomeDate = #" & Format(date, "MM/DD/YYYY") & "#" Alternatively for "advanced...

Why create a tick box to "calculate" something that can very easily be done either on the fly or can just simply be selected on the table ?? Solution: Not do it this way.

despite the fact that your tables "show" DD-MM-YYYY, the dates are stored as MM/DD/YYYY Or as per Pat's post actually as a double, but access by default recognizes dates as MM/DD/YYYY unless that is not possible like 15/01/2020 or 2020/01/05 This makes things confusing because sometimes the...

Major drawdown here is the fact that things are hardcoded, hardcoding things is an accident waiting to happen... much like many things in this example. Sooner or later the same logic will appear in different places, and sooner or later the logic will change ... and come more complex times come...

Simply replace all TempDate By format(TempDate, "MM/DD/YYYY") or if you prefer SQLDate(TempDate)

Best way to address that issue is to add a related table, to "translate" your sources into 2 sources and use the related table to pivot on. Another way is to implement a simple IIF() simular to the one @Gasman is using

TRANSFORM Count([personal Detaill new].[Client ID]) AS [AantalVanClient ID] SELECT Year([DateCompleted]) AS Expr1 FROM [personal Detaill new] GROUP BY Year([DateCompleted]) PIVOT [personal Detaill new].Source; There are a few ways of doing this, but there are so many issues here ...

This is where your troubles start(ed), never use a meaningfull value as your primary key ! I doubt the change from int to bigint is the real problem... most likely you have linked the tables and are running a query in access.... as a result it is pulling the data to access instead of pushing the...

word to the wize, use a naming convention and avoid using special characters like spaces, -@#!#%^*&( and alike. Your Account-No would be txtAccountNumber Your form BRequest would be frmBrequest Your query for that form would be qryBrequest Your table for that form would be tblBrequest Etc etc...

Classic mistake, though mistake #1 is not ... using excel.... basic mistake is to leave the data as is spread on lines. 1400 cases spread over 65000 rows roughly 50 rows per case, if the data was managed properly changing the 50 lines to 50 columns it would have allowed 65000 rows and the...

So make your first query Select equity from yourTable Where (Type = "Sales" And SaleDate Between Forms!yourform!StartDate And Forms!Yourform!EndDate) Store this query as "qrySalesPeriod" Now make a second query: Select * from yourTable where equity in ( Select equity from qrySalesPeriod)...

You can investigate the DIR function and the use of that over your current method. Another alternative is use a table to store your filenames first, then open a query which can force the filename order and fetch the filenames from the query to import the files.

You typicaly dont delete records you mark them obsolete, depending on the update date and time.... the order you import your different files should not matter.

why want to force access to import the one store first? Simply add the filename/storename to your target table running an update query after importing the file.

excel obsolete, what kind of bad trip are you on? I still do things in excel 10 times faster then most others using "new shiny" tools

Super example of making something simple very complicated. Simply cover all roof tops in solar panels, that combined with some local and decentralized storage will reduce the strain on the power grid and cover 80+% of all household energy needs with clean "Zero-Emissions" energy. That is with...

If you are working in VBA, when your form value is NULL you want to OMIT the where clause all together not "force" it to be true using NZ. The SQL solution is a poor mans way of solving a very simple problem. More over your SQL is comparing strings and Dates, resulting in Implicit conversion...

Nice that it works and nice you understand it, but it stil is less than optimal design and much less than optimal solution. If you are stuck on this design, this query would work much better SELECT Table1.[MainPCBInfo#1], Table1.[MainPCBInfo#2], Table1.[MainPCBInfo#3], Table1.[MainPCBInfo#4]...

Using numbered fields in a database is a sure fire way of making it like an excel sheet, which is a bad thing to do in a database. As I stated earlier and Minty did as well, redesign is in order to create a single table with 2 columns... 1 column holding your PCBInfo.

Really? Sorry to be harsch but that must be the worst way ever to do this.... IMHO offcourse Do you know how to add criteria to fields ? Field1 = Forms!FormName!textbox OR Field2 = Forms!FormName!textbox OR Field3 = Forms!FormName!textbox etc Why would you have a table with 5 field each field...