What are the top things you would like to see in a future version of Access?

[Alisa]

Either better remote control commands for or better documentation for low level Access commands. I'm pretty sure that doesn't make sense so here's a for instance.

If I want to split a database using the built in tool, I need direct access to a computer on the network with the database installed to do the split. There is not a command that can be run (that works) in VB that will split the database. I would like it if, anything you can do with the Access "tool" in front of you could also be done programmatically. If that is already a part of Access, then they need to document it and support it.

Yes, that is an interesting point George. I remember at one point I found that that there is actually a VBA command to generate the MDE file which was a huge surprise to me, I wonder how many other commands like that already exist that just aren't well documented (or aren't documented at all).

 

[Banana]

Pssttt... If you have Visual Studio, fire it up, create a new project and reference the Access library. Use Object Browser to look around. You'll be surprised at what Access's Object Browser doesn't show, even with hidden members shown.

 

[Alisa]

Pssttt... If you have Visual Studio, fire it up, create a new project and reference the Access library. Use Object Browser to look around. You'll be surprised at what Access's Object Browser doesn't show, even with hidden members shown.

Hence the need for better documentation Why does MS make it so hard to use the things they obviously invested a lot of time and money in building?

 

[georgedwilkinson]

With that said, they need to improve the object browser. If you can do things to Access objects in some other environment that you cannot do in Access, there's a problem.

 

[raskew]

Hi -

Re Banana's Post #10. Wouldn't take too much to modify this http://www.access-programmers.co.uk/forums/showthread.php?t=154683 to handle the 'optional' feature.

What do you think?

Bob

 

[Alisa]

Agreed, but it would also be nice if that was built in.

 

[georgedwilkinson]

Remove the 355 byte limitation (per field) on exporting data to Excel.

Invoke the QBE within VBA and format SQL from QBE into VB ready string. And/or do a direct dump of SQL from QBE to a VB formatted string.

 

[maxmangion]

Hi,

I haven't read all of the posts in this thread but the following are my wishlist (not sure if they have been implemented in 2007 version):

- update the vba code when using the command button wizard

- remove/hide certain features which are considered "bad practices" such as lookups at table level

- better image support especially on continuous forms

- be able to create exe files

 

[NigelShaw]

Im more of an asthetics person so would like to see an easy interface to integrate ribbon use instead of the XML fiasco that is currently needed. maybe a design section that visually allows you to build your ribbon and link it to code. Other people can build it so why cant Access?

also,

make the visual side of forms look and feel more like actual windows forms rather than having to download additions to create it for you.

most definately, an option to create an exe file. currently, this cant be done however, i recently used a sheet material program that was an exe. when it was opened to use, a .mdb appeared to add and update materials you use. when the program closed, it disappeared....


Nige

 

[Alisa]

Im more of an asthetics person so would like to see an easy interface to integrate ribbon use instead of the XML fiasco that is currently needed. maybe a design section that visually allows you to build your ribbon and link it to code. Other people can build it so why cant Access?

also,

make the visual side of forms look and feel more like actual windows forms rather than having to download additions to create it for you.

most definately, an option to create an exe file. currently, this cant be done however, i recently used a sheet material program that was an exe. when it was opened to use, a .mdb appeared to add and update materials you use. when the program closed, it disappeared....


Nige

I have actually been pasting all of the suggestions back into the first post so it is easier to read through everything. As far as the ribbon goes, I haven't really worked with it at all so I don't actually have an opinion, but do you think it might be better to just scrap the whole thing? I know one thing George suggested about 2007 was just going back to the way 2003 looks and feels . . .

 

[Banana]

*smack forehead*

Can't believe I didn't thunk of it earlier!

Please, *please*, for love of [insert the appropriate deity/nondeity here], make Access much more robust with regards to networking and provide error handling for networking issues.

A case in point: If the linked backend crashes or suddenly becomes unavailable in middle of a session, Access handles this in worse way possible: it spews forth a bajillion dialogs (yes, just like the good ol' days of Win 98!) with "Disk or Network Error", and if you're extra-lucky, Access sprinkle those dialogs with blue special "Access can't find blah blah" errors and if you've cleared all those dialogs, it will continue to pop *more* errors then once you've cleared that away, it may quiet down until you as much as click on a control or close a form and it throws up more errors! Ultimately, the only way out is to give Access the three finger salute.

So, please, make sure if the network get borked, do a better job of handling the event, and provide a hook for programmers to trap and fix as they can.

This also goes without saying that the same hook should be provided for the internal connection string; if something goes wrong, Access should be able to yield the control to the programmer to fix the connection string.

Hi -

Re Banana's Post #10. Wouldn't take too much to modify this http://www.access-programmers.co.uk/forums/showthread.php?t=154683 to handle the 'optional' feature.

What do you think?

Bob

This is quite excellent tool for us stuck with no such feature. As George has pointed out, when we use parameter query/prepared statement, the server already optimizes the query at time of preparation and thus does not reprepare, which is big saver on resources. I'm just guessing here, but in Access's case, if we alter the QueryDef or use dynamic SQL, Jet will optimize it everytime it is run. Could be a good or bad thing. So providing a real parameter query would require tweaking of Jet's internals, which we obviously do not have the access to. But at least we don't have to wait around and can just use your tool.

Invoke the QBE within VBA and format SQL from QBE into VB ready string. And/or do a direct dump of SQL from QBE to a VB formatted string.

This is quite an excellent idea.



Oh, one more thing... Continuous subform in a continuous subform, please. (Not sure if split form in 2007 address this? Not sure if I understand what it is..)

 

[maxmangion]

i would like to see controls on form having a different default name than the field names when created ... maybe using some kind of prefix such as cbo, txt etc

 

[Alisa]

*smack forehead*

Can't believe I didn't thunk of it earlier!

Please, *please*, for love of [insert the appropriate deity/nondeity here], make Access much more robust with regards to networking and provide error handling for networking issues.

A case in point: If the linked backend crashes or suddenly becomes unavailable in middle of a session, Access handles this in worse way possible: it spews forth a bajillion dialogs (yes, just like the good ol' days of Win 98!) with "Disk or Network Error", and if you're extra-lucky, Access sprinkle those dialogs with blue special "Access can't find blah blah" errors and if you've cleared all those dialogs, it will continue to pop *more* errors then once you've cleared that away, it may quiet down until you as much as click on a control or close a form and it throws up more errors! Ultimately, the only way out is to give Access the three finger salute.

So, please, make sure if the network get borked, do a better job of handling the event, and provide a hook for programmers to trap and fix as they can.

This also goes without saying that the same hook should be provided for the internal connection string; if something goes wrong, Access should be able to yield the control to the programmer to fix the connection string.




This is quite excellent tool for us stuck with no such feature. As George has pointed out, when we use parameter query/prepared statement, the server already optimizes the query at time of preparation and thus does not reprepare, which is big saver on resources. I'm just guessing here, but in Access's case, if we alter the QueryDef or use dynamic SQL, Jet will optimize it everytime it is run. Could be a good or bad thing. So providing a real parameter query would require tweaking of Jet's internals, which we obviously do not have the access to. But at least we don't have to wait around and can just use your tool.



This is quite an excellent idea.



Oh, one more thing... Continuous subform in a continuous subform, please. (Not sure if split form in 2007 address this? Not sure if I understand what it is..)

Yes and Yes. I can't tell you the contortions I have gone through to mimic continuous on continuous forms. And it is utterly ridiculous how much code exists in my applications just to prevent the program from crashing when the backend is moved.

 

[Alisa]

i would like to see controls on form having a different default name than the field names when created ... maybe using some kind of prefix such as cbo, txt etc

Think this sort of fits in with the whole idea of naming conventions in general, right?

 

[maxmangion]

Think this sort of fits in with the whole idea of naming conventions in general, right?
Reply With Quote

I had just the daunting task of renaming all the controls when creating a form on my mind, but yes i perfectly agree with you that an overall naming convention would be a good suggestion.

 

[Alisa]

I had just the daunting task of renaming all the controls when creating a form on my mind, but yes i perfectly agree with you that an overall naming convention would be a good suggestion.

I have gone throught that as well, with hundreds of controls on a form no less. Yuck!

 

[boblarson]

I have gone throught that as well, with hundreds of controls on a form no less. Yuck!

Check out this tool by Arvin Meyer. It is cool and helps with renaming to your convention. You can modify the code to do whatever you want as far as naming:
http://www.datastrat.com/Download/FixNames2K.zip

 

[Alisa]

Check out this tool by Arvin Meyer. It is cool and helps with renaming to your convention. You can modify the code to do whatever you want as far as naming:
http://www.datastrat.com/Download/FixNames2K.zip

Thanks Bob, I will check it out. Ofcourse, I only ever discover stuff like this AFTER I have wasted time doing it by hand, oh well.

 

[georgedwilkinson]

I can't believe I didn't think of this before.

Completely eliminate macros as they currently exist. Adopt the Excel/Word macro paradigm (using VBA) and institute a macro recorder. Integrate Application level commands into the "macro" recorder (i.e. split a database, etc.).

 

[Alisa]

I can't believe I didn't think of this before.

Completely eliminate macros as they currently exist. Adopt the Excel/Word macro paradigm (using VBA) and institute a macro recorder. Integrate Application level commands into the "macro" recorder (i.e. split a database, etc.).

Brilliant - I have always wondered why Access didn't have a recorder like Excel, just think how many posts on this very message board could be eliminated!