Search results

Despite the many changes in the UI (which few are for the better, IMO), keep in mind that the fundamental concepts have not at all changed. Tables, queries, forms, reports and code all work using the same general principles that have been in place since long before you worked with it the first...

Ah, yes... top 3 per group (top 3 per student): http://www.allenbrowne.com/subquery-01.html#TopN (again, not sure how to do that in the query designer...)

SELECT TOP 3 * FROM MyTable ORDER BY DateField DESC; Something like that ought to do (not sure how to do it in the query designer though, and an explicit field list rather than * is recommended...)

I wouldn't dream of using a designer to write queries. Raw SQL is my preference any day. There's a lot of queries that can't even be realized in the Access designer. Sometimes you can work your way around it, but that means the underlying stuff is much more complex than it has to be (if you...

That error is VBA specific, shouldn't have anything to do with the tables. Typically means that the name of the VBA project is the same as whatever function you're trying to call. Example: vba project named ThisProject, and you happen to have a function named ThisProject, so you call your...

I don't think you need to access the properties collection, and I don't think you need any sort of shortcut menu object. As I recall, the property you're after is simply a text value that takes the name of the menu, so: frm.ShortcutMenu = "" ... should suffice to remove the menu.

There's also the undocumented SaveAsText function, but I'd prefer the SQL property approach as well. Sometimes you have queries that are too complex to be correctly displayed by the designer, and will only open in SQL View. In any case, once you get the SQL itself you can throw it in some...

Attendees should be a in child table, at the Many end of a 1 to Many relationship between your meetings table and the Attendees table. Typically, one might also have a list of Employees or People or something in a different table, which would be the source for the Attendees. Probably you...

You can almost think of it as wrapping CLng() around each of the numbers: If (lngPos1 > CLng(0)) And (lngPos < Len(strAddress) - CLng(2)) Then... (it's not exactly the same, but in a high level view it works out to be the same).

... and ^ for LongLong in 64bit (not sure if LongPtr has one, being a psuedo-type). Typically you see this in use either in: a) old code, though I hesitate to use the world old: it was common in times gone past let's say, or b) shortcuts for type coersion for API calls to Windows functions...

You can access SQL Views from the Access FE, but it doesn't always make sense to do all of the querying on the backend as views: there's still a fair amount of FE queries you'll be writing as well. Hard to explain why, but it's a mix of both, IME. Regarding BLOBs, that paper was written 12...

I think it depends on what you're doing with it. The engines tend to be build in a way that makes each one a little better at this type of thing, where the other is a little better at that type of thing, etc. I don't typically notice any performance difference between various engines on a...

SQL Express gets you 10gb of db size. You can't do automated backups and such through SQL Agent (not available on Express), and you won't have access to advanced features such as Transparent Data Encryption, etc - but most people migrating from Access don't need that anyway (and if you're...

I'll definitely agree the FE and BE should be separated, for sure. However, the first step would be to split it out into two separate Access files (that's the easiest, and gets you a lot of bang for your buck, so to speak). As for the IDE, yes, Workbench is better. But... have you considered...

Ugly stuff: I've done more if it than I care to really. If you happen to access to jQuery on the site there's an ExecuteScript (or maybe just Exec?) which would make it pretty easy: (aircode) ie.Document.ExecuteScript("$('#search').text(YourTrackingNumber);") I don't work with vanilla...

Right on. Sometimes you just have to draw the line somewhere. Money isn't everything.

Have you considered using SMTP directly (something like CDO/Exchange or a 3rd party service)? Outlook automation is a PITA in the best of circumstances, and automating it through scheduled tasks is far more trouble than I've found it to be worth.

>> doing a record count on a linked table ALWAYS gives -1 << For ADO? I know for DAO it gives the count of the accessed records (which is why we should traverse them all via .MoveLast prior to reading a recordcount). >> no idea what this has to do with cursors! << I think in non-Access RDBMs...

I don't work with ADO too much, but I believe a -1 indicates that yes, there are records, but not necessarily the full count. I think in order to get the full count, you must first traverse all of the records in the table (this forces a fetch for all records, rather than the typical paging...

The 2GB limit is (maybe tied with better data security) the number one reason to move to SQL Express (usually). Pat's right on the money here. Splitting out Access BEs will cause you no end of trouble down the road. Quick edit: Pat stated 2GB limit in SQL Express, which I thought was 10GB. A...