|
Ok, I've got it working by formating the date component of my CommandText as "yyyyMMdd", but I don't really understand why I had to do it this way.
Most of the threads I read regarding similar problems talked about formating the date as;
"MM/dd/yyyy"
or
"MM dd yyyy"
or
"MM.dd.yyyy"
or
"MM-dd-yyyy"
or
"dd/MM/yyyy"
etc etc
None of these worked though. Only "yyyyMMdd" worked.
This doesn't line up with my regonal settings either. We have the date format as "dd/MM/yyyy" here in Australia.
Can anyone give a good explanation why only "yyyyMMdd" works? 
|
|
|
|
|
Paul Hasler wrote: Can anyone give a good explanation why only "yyyyMMdd" works?
yyyymmdd is the best date format in my books... it means all dates come out in date order when you return them in a query.
yyyymmdd is a standard to get around the horrors that we all have faced (I'm sure) back in the old days when someone would insert a date like "03/04/95", and depending on regional settings you would get 3 April 1995 or 4 March 1995.
|
|
|
|
|
Google for "vb.net parameterize query" and you'll find that, done without all the string concantentation, this would not have been a problem at all.
|
|
|
|
|
Thanks Dave! I Googled your suggestion and it was a bit of a revelation!
Someone needs to find the button marked PURGE on that "little black box with the flashing red light" that is the internet.
I've obviously only been mucking about with SqlCe for a week or so, and as a noob most of my searches for tutorials etc seem to have come up with the old dinosaur methods, so I assumed that's how it's done.
Parameterization is SO much cleaner and useable!
Cheers again.
Paul
|
|
|
|
|
This might be more of a framework issue, but since the code is VB....
We have a large application, written in VB.Net 3.5 and running on Vista systems using the Aero interface. During long processes, we show a form that displays continuing progress, like this:
Label1.Text = String.Format("Completed: {0}%", CInt((Count / Total) * 100))
Label1.Invalidate()
Me.Invalidate()
Application.DoEvents()
This works just fine, until the user turns to another task and a different window covers the progress form. At that moment, the form stops being updated. Moving the covering window away does not cause the form to start updating again, and the result is a useless box that taunts us, making us guess if it is almost done or stalled at 20%. A similar problem occurs with other forms of feedback such as progress bars and status controls.
Any suggestions?
|
|
|
|
|
TechBearSeattle wrote: Any suggestions?
yes. stop abusing DoEvents() and organize your app the proper way: GUI stuff in the main thread, everything that takes (or might take) more than 30 msec in one or more separate threads, possibly ThreadPool or BackgroundWorker; and all painting in paint handlers.
Here is some literature for you:
animation1[^]
crossthreads1[^]
|
|
|
|
|
Thanks, that was awfully helpful. Perhaps now you could provide references on how to retrofit a massive legacy application to make use of multi-threading? I'm sure I can find a few months to dedicate to the project.
|
|
|
|
|
I am surprised by the combination large+legacy+VB+Vista.
I don't have a reference for retrofitting such beast.
Can you break it up in smaller modules (possibly different processes) and redo the GUI?
Probably a total redesign is in order.
|
|
|
|
|
Luc Pattyn wrote: I am surprised by the combination large+legacy+VB+Vista.
Damn you beat me to it 
|
|
|
|
|
Sorry for the sarcastic response above; friends should not let friends post while uncaffeinated.
The application itself is more than 10 years old. It was originally written in VB4, was latter translated into VB6 and, starting about two years ago, translated into VB.Net 3.5. This is the database front end used by the home office of a mid-size brokerage firm and has gone through EXTENSIVE rewrites over the years to accomodate changes in federal regulations and the ignorant whims of Point-Haired Bosses. The EXE of the original, as delivered by the team of contractors, was 1028kb; the most recent VB6 version is 2844kb. Because of the number of cards that make up this mission critical house, I have been very reluctant to make wholesale changes in the code.
In summary, the application is a big, steaming pile sitting on my desk.
In the most recent version (the one in VB.net 3.5) there were some organizational changes. The visual interface (forms, etc.) and central application pieces are in one project, the core functionality and custom components are in another project, database functionality is in a third, and projects exist for interfacing with our document imaging system, our reporting system and our back-office employee management system (don't ask why that was folded in,) all tied together into a single solution. Some order was imposed on the database module, forced largely by the switch from RDO to ADO.Net, but by and large, the code was merely translated rather than redesigned from scratch like it should have been: we simply did not have the time and resources to do that.
It should be possible to redesign the main project to make use of multithreading, but that leads to a rather more substantial problem: my company does not pay for tech training, so I would have to do it on my own and I don't know squat about multi-threading. I'd like to think that I am a pretty competent programmer, but that is never something I've had to do before. Contracting is not a realistic option, as my boss tends to higher whoever has the lowest fee and does not ask my opinion before inking the contract.
I was really hoping that there was a simpler solution.
|
|
|
|
|
Well by lack of any other option you might try to refresh the form and the controls individually.
No guaranty that it will work haven't try'd it.
Other than that you could try to make sure no other form can be displayed over that one.
Again a very bad solution and not sure if it will work.
|
|
|
|
|
if (big if) you have a clear separation between GUI stuff and everything else, then you could use just two threads: the main thread for GUI stuff, one new thread for everything else including database accesses, networking, computations, whatever. All you need then is a good interface between those two, so the back-end can remain what it is and read and write data structures getting/passing information to the front-end GUI. It is not really hard, however there are many ways to do it wrong, and depending on the number of forms/screens you currently have, it may be huge.
You should not attempt this on a big app right away; take your time to get something small to work, so you really understand it and then can judge for yourself.
|
|
|
|
|
Ah, well. Multithreading is something I've been wanting to learn, as it would help in a number of other apps I have to maintain. I just have to work out a way to make this enough of an issue so the PHBs allocate the time and resources I need to get this worked out. (Insert evil smiley here.)
|
|
|
|
|
I'm guessing that's sarcasm.
TechBearSeattle wrote: how to retrofit a massive legacy application
Legacy? with vista Aero interface and vb.net 3.5???
Luc is correct if you want this form to keep updating you'll have to put your code into a separate thread and stop using doevents().
TechBearSeattle wrote: I'm sure I can find a few months to dedicate to the project.
If the project had been designed correctly from the start you wouldn't be in this kind of trouble now.
|
|
|
|
|
Alas, yes: this is a legacy system running on Vista with Aero. See my post above.
|
|
|
|
|
using VB6 and Crystal Report10, Report X contains subreport Y and Z (e.g)
When i click button, it gives error as
"Query Engin Error 'Error Code: 0x800a0e78'
Source Adodb.RecordSet
Description: Operation is not allowed when the object is Closed"
NOTE: When i use break point and parse line be line, then it works fine.
My Code is as:
Public Function ShowNELogReport(ByRef rsNELog As ADODB.Recordset, ByRef rsPower As ADODB.Recordset, ByRef rsSystemStatus As ADODB.Recordset, ByRef rsRequirement As ADODB.Recordset)
Dim Report As New rptLogMain
On Error GoTo Err
With rsNELog
If Not (.BOF Or .EOF) Then
.MoveLast
.MoveNext
'Report.Database.SetDataSource rsSearchReport
Report.Database.SetDataSource rsNELog
Debug.Print Report.Database.Tables.Item(1).Name
'Report.ReadRecords
Report.Subreport1.OpenSubreport.Database.SetDataSource rsPower
Report.Subreport2.OpenSubreport.Database.SetDataSource rsRequirement
Report.Subreport3.OpenSubreport.Database.SetDataSource rsSystemStatus
crViewer.ReportSource = Report
crViewer.ViewReport
Else
MsgBox "Record Not Found", vbInformation
Unload Me
End If
End With
Exit Function
Err:
MsgBox Err.Description
End Function
|
|
|
|
|
hi.. I m working in VB in Visual Studion .Net. In my project I have two forms. I m declaring a public array in form1 which i want to use in 2nd form (form2) also. On form1 i have a button which when clicked form2 will be shown. I want that contents of array in form1 should be acessible in form2 also. But i m facing the problem that how to open form2 on button click in form1 and use array of form1 in form2.
So, Is there any solution for this???
|
|
|
|
|
If the array is declared as public then all you need to do is preface the call to the array with form1
i.e textbox1.text = form1.myarray(0)
|
|
|
|
|
Personally this is a very BAD idea.
Forms are objects that should encapsulate the data within them. At no time should one object just simply reach out and grab hold of data inside of another object. This is really one of the major tenets of OOP design.
That does not mean that you can't talk between forms, but it should be done properly via an established interface.
You should be providing an interface (functions, methods, or custom properties) on your forms for allow that type of communication to happen. This gives you a way to not only gain access between data on forms the proper OOP way, but also gives you the ability to provide data validation, authentication when needed, and also perhaps some contention detection when that may be needed also.
Please, NO public variables on forms! Forms are objects just like a class is. You don't open up a variable inside a class by making it public, you provide an accessor method to get to it. RIGHT? That's how you are doing in in your classes? Please say yes?
Forms are no different.
|
|
|
|
|
What!? I just use Option PublicEverything so I don't have to think!
All kidding aside, though, Ray is right. Just need to make a public accessor for the array, and all is well.
|
|
|
|
|
Actually I think he might be better to just use a seperate module for his public data. The forms should only contain data that is very specific to that particular form (which usually means it doesn't need to be public). Everything else such as functionality should be in modules or classes.
|
|
|
|
|
I can agree there, but then you still should not just reach out form the form and access the public object. It should be passed to the form upon creation via the forms constructor.
NOTHING in my opinion should be simply accessible via being public.
|
|
|
|
|
My Apologies. Of course you are right. You should implement public properties rather than declaring variables Public in any Class. My Bad. 
|
|
|
|
|
I want to show the WaitCursor when my app starts while it does some preparations before it shows the main form and starts the message thread.
So I can't use MyForm.Cursor = Cursors.WaitCursor because the message thread is not running yet.
Is there a way to change the windows cursor in another way?
|
|
|
|
|
Windows.Forms.Cursor.Current = Windows.Forms.Cursors.WaitCursor
Windows.Forms.Cursor.Show()
'Never argue with an idiot; they'll drag you down to their level and beat you with experience.' ~ anonymous
'Life's real failure is when you do not realize how close you were to success when you gave up.' ~ anonymous
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
