Does reSELECT [tblmytable] clear a filter? - visual-foxpro

I'm converting a Foxpro app and I'm having a bit of trouble with database table referencing/selection. I'm not in a position to run the Foxpro code as I only have code dumps with which to work. If someone could help me understand what is happening here I'd be most grateful. Yes... I searched.
SELECT tblMyTable
Set Filter To Inlist(cbid,123)
SELECT tblMyTable
Does the second Select simply reselect tblMyTable and clear the filter?
If not is a second instance being opened so you have one that’s filtered and one that isn’t?
If so how do I reference each instance since they have no names? Automatically 1 and 2?
Lastly if I’ve got it completely wrong just give me a small clue and I’m on it. Thank you!

I see that you are being misguided.
Second select has no special meaning. That line is not needed at all, but wouldn't do an harm either.
If it were a view, then 'refreshing' a view is done by using Requery(), not by doing another 1 or more selects.
In fact, 'set filter' is on the list of (almost all VFP developers') "never to use commands" , exceptions like this might happen unfortunately.
If you are doing a conversion by only using code dumps and no VFP environment at all, then your task should be extremely hard. I would instead prefer a rewrite from scratch. That would be faster even for seasoned VFP developers.

Related

Using of Sitecore's XPath builder to test queries

i'm getting started with sitecore and i just discovered this tool sitecore offers to test our queries:
My problem is i just can't make it return results and i do know this query works perfectly cause i've been using it on my project right now.
There is probably a problem of syntax somwhere i don't know.
Thank you for helping me to put some light on this !
It's a bit difficult to tell due to how bits of that are redacted (there might be other syntax errors hiding under the boxes), but there's one obvious issue there, I think: You don't need the "query:" bit on the beginning of what you've typed.
In general, if the API or web form your filling in can only take a query expression you can leave the "query:" bit off. But if you're putting text into somewhere that might take a query or might take something else then "query:" is needed to tell Sitecore what it's looking at.

Order by Datetime - Report Builder 3.0

I'm new here (I guess you already noticed x3...). I'm the engineer Diana De La Torre, I'm actually "on training" in Fresnillo PLC company so they wanted me to develop a Project based in the the SQL server reporting services (SSRS). They want me to make reports of some processes in this company with Report Builder 3.0. I've learned a lot about it but I just have a trouble when I try to order the report results by "BitacoraTime" (That is a datetime field).
It just won't work at all. I've tried to change the sentence and to order this report by month and/or day and It won't work either.
I've tried a lot of things and looked everywhere here on the internet.
I "tested" the same Query in the SQL Server Management Studio and all the sentences I tried to put an order to the results are working well, so it makes me think the trouble in here is the Report Builder 3.0 itself.
I really need a hand in here, I don't have enough experience to figure this out myself when everything I tried didn't work at all and I'm a Little bit desperate.
I would really appreciate if someone in here just give me a clue or something.
Thank you so much for taking the time of Reading this. :3
-Diana De La Torre.
(Ps: Sorry if my english is bad heh. I'm still improving it x3)
I think I could solve this problem.
I really thought you could order a Tablix by a Query or by clicking the right button on it and selecting how do you want to order the results but nothing of this worked.
But suddenly I found out that clicking the right button on the exact field you want to order by you could find an option called "Dynamic Sorting" and you just have to configure that option so when you run the Report you can click on that field so it orders the results Ascendant or Descendant.
This is not exactly what I wanted because I wanted the results to be in order by just running the report model but Oh well, it won't work anyway.
I hope this can help some other people who present this problem.

Magento code changes in local don't work

I'm trying to fix the Magento search issue where 'OR' is used for comparison of multiple search terms instead of 'AND'.
I've seen quite a number of suggestions on the web regarding how to fix this, and the general idea is as follows:
Copy
app/code/core/Mage/CatalogSearch/Model/resource/Fulltext.php to
app/code/local/Mage/CatalogSearch/Model/resource/Fulltext.php and in the copy, change the instances of 'OR' to 'AND', where the SQL queries are built.
However, my changes don't seem to work as expected and what is even more confusing is that the prepareResult() method (which is where the SQL changes above are made) doesn't even seem to run at all when searches are done. I've tested this by putting some debugging code in the function.
I've used the same debug code to verify that the file gets loaded. But the debug code doesn't run when inserted at the prepareResult() function. (The debug code basically writes to a file on disk).
What am I missing here?
Kindly note that this is not so much about the right way to accomplish the end goal of fixing Magento search. I'm aware it's best done via an extension. I'd just like to figure out why prepareResult() isn't being called as expected.

Joomla 2.5 component

Is it possible to make a 2.5 component without using TableHelloWorld class and all that field type stuff like from here. Or is it compulsory?
http://docs.joomla.org/Developing_a_Model-View-Controller_Component/2.5/Using_the_database
The system will function without it fairly well actually. All you actually need to get something running is a base file named after your component, a controller.php file, and the view as outlined in this section: http://docs.joomla.org/Developing_a_Model-View-Controller_Component/2.5/Adding_a_view_to_the_site_part
From that you will get something that runs and loads. And if you choose you can just make raw sql queries to the database.
That being said, the framework is there to help you, not to hinder you. I've cut a lot of corners over the years, and almost always you end up regretting it later. Feel free to play around with skipping the pieces, but just remember that there are pieces out there that can help you with all kinds of important things that you may not think you need right now. (Binding input, table row hierarchies, and check-in/check-out functionality are just a few that come to mind that I'm glad I didn't have to make myself.)

LINQ Conflict Detection: Setting UpdateCheck attribute

I've been reading up on LINQ lately to start implementing it, and there's a particular thing as to how it generates UPDATE queries that bothers me.
Creating the entities code automatically using SQLMetal or the Object Relational Designer, apparently all fields for all tables will get attribute UpdateCheck.Always, which means that for every UPDATE and DELETE query, i'll get SQL statement like this:
UPDATE table SET a = 'a' WHERE a='x' AND b='x' ... AND z='x', ad infinitum
Now, call me a purist, but this seems EXTREMELY inefficient to me, and it feels like a bad idea anyway, even if it weren't inefficient. I know the fetch will be done by the clustered primary key, so that's not slow, but SQL still needs to check every field after that to make sure it matches.
Granted, in some very sensitive applications something like this can be useful, but for the typical web app (think Stack Overflow), it seems like UpdateCheck.WhenChanged would be a more appropriate default, and I'd personally prefer UpdateCheck.Never, since LINQ will only update the actual fields that changed, not all fields, and in most real cases, the second person editing something wins anyway.
It does mean that if two people manage to edit the same field of the same row in the small time between reading that row and firing the UPDATE, then the conflict that would be found won't be fired. But in reality that's a very rare case. The one thing we may want to guard against when two people change the same thing won't be caught by this, because they won't click Submit at the exact same time anyway, so there will be no conflict at the time the second DataContext reads and updates the record (unless the DataContext is left open and stored in Session when the page is shown, or some other seriously bad idea like that).
However, as rare as the case is, i'd really like to not be getting exceptions in my code every now and then if this happens.
So my first question is, am I wrong in believing this? (again, for "typical" web apps, not for banking applications)
Am I missing some reason why having UpdateCheck.Always as default is a sane idea?
My second question is, can I change this civilizedly? Is there a way to tell SQLMetal or the ORD which UpdateCheck attribute to set?
I'm trying to avoid the situation where I have to remember to run a tool I'll have to make that'll take some regexes and edit all the attributes in the file directly, because it's evident that at some point we'll run SQLMetal after an update to the DB, we won't run this tool, and all our code will break in very subtle ways that we probably won't find while testing in dev.
Any suggestions?
War stories are more than welcome, i'd love to learn from other people's experiences on this.
Thank you very much!
Well, to answer the first question - I agree with you. I'm not a big fan of this "built in" optimistic concurrency, especially if you have timestamp columns or any fields which are not guaranteed to be the same after an update occurs.
To address the second question - I don't know of any way to override SqlMetal's default approach (UpdateCheck = Always), we ended up writing a tool which sets UpdateCheck = Never for appropriate columns. We're using a batch file to call SqlMetal and afterwards running the tool).
Oh, while I think of it - it was also a treat to find that SqlMetal also models relationships to set a foreign key to null instead of "Delete On Null" (for join tables in particular). We had to use the same post-generation tool to set these appropriately too.

Resources