Hi,

I'm trying to create a parameterized query with a tableadapter against an .mdb datasource. Apparently, for SQL Server one can use "@paramname" in the SQL in the Adapter to indicate the usage of a particlar parameter, then run the query like so:

adapter.Fill(table, "param")

With the .mdb backend though, I can't seem to find the method for creating a parameter in the TableAdapter query. I have the default Fill method, then I would like to add another query:

"SELECT fldID, fldFileExt FROM tblFiles WHERE lfdID = @paramID"

but it won't let me go through with this (could not parse '@paramID').

Any suggestions? Many thanks...

Figures, search the net for an hour, give up, post here, then find it...

"SELECT fldID, fldFileType FROM tblFiles WHERE fldID = ?"

OleDb uses sequential parameters, unlike SQL Named params.

Thanks anyway, maybe someone else will find this usefull.

>> OleDb uses sequential parameters, unlike SQL Named params. <<

Well ... you can indeed use sequential parameters if you like, but OleDb definately accepts named parameters as well. As an example, the following C# code uses a named parameter to fill a DataTable and populate a DataGridView with an ACE (Access) datasource ...

Interesting... It wouldn't let me include a named parameter through the Dataset Designer when adding a query to the TableAdapters, but I tend to like the coded solution a little better anyway. Sequential parameters sound like a problem waiting to happen anyway, so I'd much rather go with Named ones.

Thanks for the info... trying to find my footing with this stuff is proving to be quite a challenge, and every little bit is going a long way.

Cheers,

One bit of advice that I would suggest is to avoid using the Designers except with laying out a form. It makes for quite the mess, and you rarely get a full understanding of what is capable and how to effectively leverage that for your needs.

I often run into people who learn solely how to work with the Designers, and then when you go to provide them with a solution to something, they are completely dumbfounded at the concept of not using a designer. They don't get the methodology, and they struggle to pick up syntax.

JMO.

- Anthony

>>JMO.<<

I like it. All I really know is Access and I've always followed that philosophy with it, so it's definately nice to know that I can continue doing so. The learning curve is so much steeper here that I'm not sure what I can/can't get away with, so believe it or not that comment/advice really does help a lot.

Many thanks.

>> All I really know is Access <<

I know the feeling. I have been using C# for about 2 years now with coming in to the fold with only my Access/VBA knowledge. C# (.Net) is so vast it is mind boggling and I find the I am constantly going to the web to be reminded of syntax or something that I think I should remember. Its very difficult to go from a "BigGun" or "Go To" guy (ie: I know a lot of stuff in the scope of Access/VBA) to a "Go Where?" guy (ie: I am always asking 'how can I do this in C#'?) guy (IMG:style_emoticons/default/dazed.gif)

A couple of points that has helped along the way:

+ C# (.Net) works off of a 'disconnected' philosophy by default, unlike Access. What that means is that you connect, get what you want into memory, disconnect; modify as appropriate; connect, commit the changes to the database, disconnect. Access works is pretty much geared to being connected (ie: bound forms and reports) -- plus Access handles a ton of "stuff" on its own (navigating, reading data, committing data, etc.).

+ C# is a compiled language, so it all needs to 'make sense' at design time. That can get you at times because in Access/VBA so much can be done and resolved at run time. Now with VS 2010, run time type stuff is increasing, plus the depth of knowledge I pocess with C# is not THAT deep, so I may have mis-stated this point to some degree, but hopefully the concept I am trying to convey makes sense (IMG:style_emoticons/default/dazed.gif)

Fortunately, I was always of the style to write everything in classes in a "disconnected" (read "unbound") state in Access, so the switch was not that difficult. What I find taxing is in providing help to many that are new to the language. Most jump to designers, and since I never messed with them, I usually can't answer them in a form that will satisfy their need without hoping to have VS.Net available to me at that moment.


I prefer this style, IMO, it makes 10x more sense than the way Access does things at runtime. If I cast a variable incorrectly, or I have other errors within my code, I would rather it prevent me from compiling. It makes error handling much more efficient to the point that you are coding to avoid error rather than coding to account for unknown potential error.

I do agree that the language is so vast that it is hard to say that one is a guru within the language, as we used to be able to do in Access.

- Anthony

I 1/2 agree Anthony .. (IMG:style_emoticons/default/smirk.gif) ..

Connected vs Disconnected:
I prefer the 'always connected' nature of Access, but I do understand the benefits of the two paradigms and can work within either. I still maintain that the niche the Access development is difficult to beat in many scenarios --- ie: internal app, Forms, Data, and Reports.

Compiled Language:
I do like the tightness of the code created in the .Net environment, but I do like the flexibility and conveinience offered by runtime resolution of some stuff.

Guru Status:
We are in one accord here! It seems that you can carve out specialties within the language and be a guru in that area (ie: database manipulation), but then just get by in other areas (ie: http communications).

---

Ultimately, its good to be flexible as a programmer/developer to go with what is best for the task at hand, or the policy in effect! (ie: C#, Access, ??; Connected/Disconnected), which I think is a common philosophy among many.

I wrote, and rewrote, a few different responses to this. Trying to concoct some elaborate explanation for my preference to unbound database interactions, but in the end, the response was simplistic and unavoidable. I'm a control freak. I can't give Access the power to run me.

- Anthony

Do you guys have any examples of one vs the other in this? What can we handle runtime with Access that has to be "done" in C#? I'm assuming none of us are in the habit of leaving out the Explicit in VBA and taking shots in the dark on the fly, so to speak, and the only other scenario on the VBA side that comes to mind would be late-binding.

I'm afraid I'm not fully following the concept...

thanks again for the various input/discussion, always appreciated

>> Do you guys have any examples of one vs the other in this? What can we handle runtime with Access that has to be "done" in C#? <<

In Access:
Forms("MyForm").Controls("MyControl").Value = "MyValue"

In C# that is not something you do, an equivalent in Access (VBA) that would resemble the explicitness C# requires would be:

Form_MyForm.MyControl.Value = "MyValue"


Basically the compiler of C# needs to be able to resolve all references, otherwise your project wont compile.

Also, C# is very strongly typed so in Access we can do "tricks" like this:



The above equivalent in C# would not even compile. In C# the conditional expresion must return a boolean, something like this in VBA would illustrate the explicitness needed in C# to compile:



----

Does that help?

>>Does that help? <<

Yep, it does.

One of my next tasks was to refer to control names such as control1, control2, control3 etc through some sort of Controls("control"+num.ToString()), but based on what you just said...

thanks,

>> but based on what you just said... <<

Yep ... you may want to investigate the use of the .FindControl method. I have never used it, but from the skimmed readings of posts requesting to do as you are proposing to do, the FindControl method was mentioned as part of the solution.

But ... my question is why do you need to loop the controls in this manner -- In other words, what causes you to refer to your controls this way as apposed to a direct reference?

I've got a nested grid that expands based on the form size, which holds a series of like controls. I would like to hide/show them based on the size of the form. If Access were able to capture form resizing, I would approach it through a few calculations and reference the controls that way, effectively leaving me with a more or less infinate amount of "play".

In this case, it would only be two or three controls that are hidden/shown. There's probably other ways to do it, but they aren't important enough to say, put them into a scrolling box (not sure what that's called, haven't done it yet). Just some miscellaneous related data that's not very important but using otherwise wasted screen real-estate

Fun stuff!

>> If Access were able to capture form resizing <<

?? ... In Access we can capture resizing ... C# can too for that matter.

----

I don't think I am following what your goal is (IMG:style_emoticons/default/dazed.gif) , but thats ok (IMG:style_emoticons/default/thumbup.gif) . Just trying to get the thought processes of your design in the "compiler based" thought process. Also, with respect to resizing controls, you may want to check our "Anchoring" and anchor all four sides of your controls.

Some time back I thought to make a media handler in Access for music, pics, links, vids etc, but handling media (or rather, presenting it) isn't really a strong point for Access. I thought it would be a good intro/pet project for C because there's a fairly wide variety of components, including and underlying organizational database for the various types of media.

I'm starting with images because they're the easiest, IMO. Picture the XP windows slideshow view for pictures... a row of thumbnails at the bottom and a main display. Now picture the tag and rating footer bar that Vista/Win7 has for various media.

My form layout is a combo of the two, but with dropdown expander at the top for properties. Below that is the main image, and to the right is a sidebar (another expander) of thumbnails for related images. When the form is resized, or the properties expander is collapsed/expanded, the thumbnail sidebar height (and main image) changes with it. Therefore, the number of image controls for thumbnails that can fit in the expander grid is dynamic.

This is all working fine, but the image controls are hardcoded, whereas in Access I would use an indexing naming scheme for the controls and run the fill procedure off an integer array, appending the current int to the control name for the reference. In C# so far I've just hardcoded for the max amount of controls that would fit in a high-res display.

In a perfect world, the sidebar engine would create controls on the fly and manage them as required with no max amount. So if I buy a super-moniter in two years with a y-res of 15,000, there would still be as many thumbnails in that sidebar as can fit in it. I suppose my reasoning behind it is residual of the database rule to never design yourself to a limit. Just off the top of my head, I guess if I really wanted to I could probably create controls on the fly in C#, as long as I'm referencing them explicitly, but for the time being I'm fine with this.


The Anchoring is great... in fact, the entire WPF layouts are like cutting butter after the bludgeoning required to make Access do stuff half as slick. I'm really liking it.

Here's an excellent example:

Five small images in a row, rating stars. Rating value can be from 0 (null/unassigned) to 5. Controls are rating1, rating2, rating3, rating4, rating5.

Depending on the current rating or mouseover status, toggle the image of the approriate controls between the resource images starUnfilled.gif and starFilled.gif.

In Access, the routine would resemble something like this:



With C#, apparently I need to hardcode each control:




Or something along those lines anway, likely a switch statement instead of the ifs but I'm unfamiliar with the syntax offhand and this is conceptual aircode anyway.

But the point, each control in c# need be accessed directly? No dynamic referencing?




edit:
or this:


There must be some way to loop or enumerate controls that start with "rating", I'll do some searching for creating custom control collections or something along those lines. For the meantime, that works though... clunky, but it works. Baby steps...

Hi Jack and Brent

After using Access for what appears to be some time based on your expertise, why did you choose C# vs VB.NET? Having worked with Access for 9 years now, writing in VB.NET feels more natural to me. Your thoughts and experience is appreciated.

Ryan

>>why did you choose C# vs VB.NET?<<

When I started looking at other languages, I first started playing with C++ and I was immediately struck by the simplicity, or maybe better put as strength, of the language. Granted, as far as I got in C++ was creating a few dlls for math functions (easy as far as programming goes), before moving on to my playing around with C#.

Before I started with C# I took a few side-by-side comparisons against VB, and VB just seemed a little more 'clunky' to me. Please take no offense to this next statement, but I feel like VB.Net is 'dumbed-down' from a real programming language (again, please no offense, it's really the only way I can truthfully describe how I feel about it... I understand that both are one in the same as far as capability and it is purely programmer choice, and by no means do I harbor any prejudice against anyone prefering vb.net)

As a simple example, the power or a for loop in C appeals to me greatly over that of VB:


vs


The more complex the code gets the more I find myself liking the C syntax much more. In particular, the lack of whitespace meaning (and therefore requirement for line breaks) just works wonders for me as efficient coding.

Again, no offense towards VB users, but that's really the only way I can think to describe it: C is just more compact and to-the-point, IMVHO, of course!

Cheers,


edit: I guess probably it can be chalked up to the quote I keep at the bottom of my signature. VB seems to have added much (or maybe that would be better put as retained much) in an effort to make things easy for those used to legacy VB, but to me C# is the natural choice.