I need to read from and write to Excel spreadsheets using Delphi 2010. Nothing fancy. Just reading and writing values from specific cells and ranges on different sheets. Needs to work without having Excel installed and support Excel 2007.
Some things I've looked at:
I've tried using ADO, which works OK for selecting everything in an entire sheet, but I haven't had much luck reading specific cells or ranges.
NativeExcel looked promising, but it doesn't seem to be in active development, and they don't respond to e-mails.
Axolot has a couple of products. The main product seems to be very functional, but is pricey. They have a lite version, but it doesn't support Delphi 2010.
Any recommendations? Free would be great, but I'm open to a commercial solution as long as it's reliable and well supported.
TMS Flexcel - I know it looks like a reporting component for Excel (which it does very well and is a very handy tool to have in your toolkit) but it also includes components for reading and displaying Excel files. I've been very impressed with how well Adrian Gallero seems to know the Excel API, including Excel 2007.
http://www.tmssoftware.com/site/flexcel.asp
Not free of course, but at 75 Euros I think it's good value.
I've had very good luck with ADO, provided the Excel sheet is a fairly straight-forward row/column layout.
The key with using ADO, I've found, is treating the Excel sheet like a database. If your Excel sheets are primarily straight row and column layouts, just treat the rows as database records and the columns as fields. Navigate to the desired row first by searching for a particular column (field) value (preferably something unique), and then read the desired cell in that row by referencing the field that is the column name.
If your Excel sheets are more free-form, then it will be more difficult.
Don't write off NativeExcel. I have used it for a couple of years now with excellent results. It's fast and versatile. I use it to produce a nicely formatted multi-page spreadsheet with frozen panes, formulas in cells, and data from a client's database for them to use for input and then send back to me. My clients were really thrilled when they got the first spreadsheet from me because it reduced their workload tremendously and it was fairly intuitive for them to use.
I don't know why they have not responded to you because I have updated their package at least a couple of time over the last two years. When my license expires, I definitely intend to renew.
I'd recommend SMImport / SMExport from http://www.scalabium.com
Mike has always been really helpful and quick to respond.
What really helps is if you have some kind of control over the layout of the excel file.
I have built a whole unit and acceptance testing framework where the data and the test controls are all contained within an Excel spreadsheet.
I did everything through ADO. You can restrict your ADO SQL query to a whole sheet, a named range or any range for the matter. In my opinion and experience, this method is very powerful.
Two things that did cause me some problems :
1. depending on how your sheets are named, ADO might or might not see them (again, if you have control over the layout, great !)
2. be careful about the data type ADO returns when you read data i.e. it might show numbers as strings. This is because ADO tries, IIRC, to guess the data type based on the first few rows.
Disclaimer : I have never used any of the tools mentioned above. ADO did the trick for me, and I feel more in control since I wrote the code for my framework (save the ADO part obviously...).
Bruce, I've used the Axolot XLSReadWriteII component for going on 10 years now. It's been very good, and their support forums (while lite on content) seem to be monitored pretty well. The XLSReadWriteII2 version is blindingly fast, and supports all sorts of things like charts and graphics, named ranges, adding formulas on the fly, cell formatting (including borders and shading, merging cells, vertical and horizontal alignment, auto-width column sizing, and so forth).
I haven't upgraded to the latest version (we're still using XLSReadWriteII2) because we can still use the Excel XP format files, and I haven't used the XLSMini at all. I can say really good things about the full product, though; in fact, I just used it for a couple of database export things this past week.
If you decide to go that route, I have a bunch of notes about how to do different things that might be useful; if you want them, drop me a note. I also have a Delphi 2007 app that just shows how to do different formatting and alignments; I actually reproduced an existing, fairly complex report in Excel complete with all of the formats, borders, etc. that I'd be glad to let you have as well.
DISCLAIMER: I have no connection with Axolot or any of their employees. I'm just a very happy customer who learned of the product at a previous job, and was impressed enough to buy it when I started my current one.
Don't bother with Axolot's XLSMini (lite) version. I haven't purchased either of them yet, but I asked about Excel 2007 support in early 2008 and Lars told me XLSMini was based on the XLSReadWriteII and that both would be updated with Excel 2007 support at the same time. XLSReadWriteII has had Excel 2007 support since April 2008; XLSMini still doesn't have it.
With great luck, I've used Axolot for some years now. The support forum isn't exactly brimming with messages, but maybe that's because it works so well?
You can use ADO connection string like
http://www.connectionstrings.com/excel
than include the options (in the third tab of ado connection string):
Extended Properties=Excel 8.0;HDR=Yes;IMEX=0
for security purposes Microsoft prevent modifications (with IMEX=1)
http://support.microsoft.com/kb/904953/en
Sample SQL (don't forget the brackets):
SELECT * FROM [Sheet1$]
The only thing you can't do, is deletion:
http://support.microsoft.com/kb/257819/en
So to delete a row make it empty!
You can also use SQL via ADO to export:
YourADOConnection.Execute('SELECT * INTO aSheet IN "'+ExtractFilePath(ParamStr(0))+'Exported.xls" "Excel 8.0;" FROM YourTable');
I would advise to go for an option where you don't need Excel installed on the machine. I once used a component that could easily fill in some data in one sheet without needing excel installed. I would also do most of the Excel work in the Excel sheet itself. And just use the components to fill in some data on the sheet.
My 2cts.
Related
I've searched and searched but found not documentation regarding creating a screen form for IBM INFORMIX-SQL Version 7.51.FC1XC. I've plenty of form examples but no documentation to tell me how to change these forms.
Many thanks in advance for some help in pointing me in the right direction.
Thanks,
Lloyd
General outline
It depends a bit on what changes you want to make. The starting point is the .per file, which is a plain text file that you can edit with any suitable text editor.
If you want to change the text on the screen, you edit in the changes you want, keeping the data fields between square brackets unchanged (in size, and usually in relative position).
If you’ve added a column to the table, you’ll need to add a new field for it at an appropriate place in the form with an appropriate field tag. You’ll also need to add the tag to the attributes section and identify the table it comes from, and add suitable field attributes.
If you need to add a new table or an extra screen, you have to work a bit harder, but you should be able to follow what’s already there for guidelines. Setting up joins etc requires an example, but the chances are you won’t need that.
Don’t under-estimate the value of generating a default form for a new table and then editing relevant information from that into the existing form.
$ sformbld -d temp-form-name stores extra_table
That gives you a temp-form-name.per file for table extra_table in the stores database.
If you're into (still useful) historical artefacts, you could look up Using INFORMIX-SQL, 2nd Edition by one Jonathan Leffler. It's only available second-hand. It's skewed towards Informix SE or Standard Engine (Informix Online was released the year before the 2nd Edition was published), but most of what it says still applies.
Documentation
There is documentation available on the IBM web site. Finding it is tricky. Nominally, the easiest starting point is probably http://www.informix.com, which will lead you to a relevant section of the IBM site. The ‘www.’ part matters; omit it and you go to a different, more general (and hence less useful) part of the IBM web site.
However, the referenced site makes it hard to find the documentation. I started at a different point, the IBM Informix 12.10 Knowledge Center. In the 'more information' section, I clicked on Download PDF Books, and from there clicked on links which lead to Publications for Informix 4GL. Once there, I select the 'Individual Publications, by Product and Version' link for Informix 4GL v7.50.xC5, from whence you can download:
Informix SQL Reference Manual v7.3
Informix SQL User Guide v7.3
Yes, there's no easy way around needing to know that the Informix SQL manuals are bundled with the Informix 4GL manuals, nor that Informix SQL is product separate from the SQL dialect of the Informix server, which might otherwise be termed 'Informix SQL'. Once upon a long time ago, it was correct to refer to INFORMIX-SQL or Informix-SQL as distinct from Informix SQL, but that got changed to suit marketers. It's also very subtle.
I have ~10 excel files which are produced by a third party and updated each night and are available as a download. They contain ~ 10 fields (all short text / dates) and between ~10,000 and ~1m rows in each.
I'm planning to create a simple web application to enable people to search the data. I'll host it on AWS or similar. Search load will be light maybe ~1000 searches / day.
I have to assume that all the records are unique each night and need completely replace the online dataset.
It's relatively simple for me to convert the data from the excel files into a database such as Postgres and create a simple search on top of it.
My question is how do I deal with the time it takes to do the database update each night? Should I create two databases and have my application alternate between them every other night?
What is a typical strategy for dealing with a situation like this?
My current skill set is Ruby/Rails/Postgres building and simple(ish) web apps. I've been intentionally vague about technology because I'm open minded about what to use. And I'm quite happy to learn something new to solve the problem.
If you do all updates in one stransaction, you don't need too dbs - all the time you updtae tables people see "old" version, just a moment after COMMIT they will see all "new"...
Programming Language: Delphi 6
SQL Server in The Back end.
Problem:
Application used to hit DB each time we needed something , Ended up hitting it for more than 2000 times for getting certain things, Caused problems with application being slow. This hitting DB happened for a lot of tables each having different structure and different number of columns. So I’m trying to reduce the number of calls.
We can have about 4000 records at a time from each table.
Proposed Solution:
Let’s get all the data from DB at once and use it when we need it so we don’t have to keep hitting the DB.
How Solution is turning out so far:
This version of Delphi doesn’t have a dictionary. So we already have an implementation of a dictionary from String List (Let us assume that implementation is good).
Solution 1:
Store this in a dictionary that we created with:
A unique field as a key.
And Add rest of the data as strings in String List separated like this:
FiledName1:FileValue,FieldName2:FieldValue2,…..
Might Have to create about 2000 String List to map data to key.
I took a look at the following link:
How Should I Implement a Huge but Simple Indexed StringList in Delphi?
Looks like they could move to a different DB not possible with me.
Is this a sane solution?
Solution 2:
Store this in a dictionary with List.
That list will have Delphi Records.
Records can’t directly be added to so I took a look at this Link:
Delphi TList of records
Solution 3:
Or Given that I’m using TAdoQuery should I use Seek or locate to find my records.
Please advice on the best way to do this?
Requirements:
Need Random Access of this data.
Insertion of data will happened only once when we get all the data , per table as we require them.
Need to only read the data , don’t have to modify it.
Constantly need to search in terms of primary key.
In addition to changing the application we have already done good indexing on DB to take care of things from DB side. This is more to make things run well from the application.
This sounds like a perfect use case for TClientDataSet. It's an in-memory dataset that be indexed, filtered, and searched easily, hold any information you can retrieve from the database using a SQL statement, and it has pretty good performance over a few thousand reasonable-sized rows of data. (The link above is to the current documentation, as I don't have one available for the Delphi 6 docs. They should be very similar, although I don't recall which specific version added the ability to directly include MidasLib in your uses clause to eliminate distributing Midas.dll with your app.)
Carey Jensen wrote a series of articles about it a few years back that you might find useful. The first one can be found in A ClientDataset in Every Database Application - the others in the series are linked from it.
Is "Replacing non-visual components with code" a proven optimization technique in Delphi 7. Mainly with respect to Database Access.
The Web site you cite talks about replacing a dialog-box component with code that would display the dialog box without the use of any component. The alternative is to write a couple of lines of code to set up and display a dialog box whenever you need one, and to skip the component altogether. It's not really an optimization in speed or size, though. It's not a speed optimization since your code would do exactly what a component would have done anyway, and it's not a size optimization because the space any one component occupies in a program is negligible.
Database components aren't so easily replaceable as dialog-box components. Nearly everything in Delphi is designed to use descendants of the standard database components. If you don't use the components, then you won't be using any of Delphi's database capabilities at all. You can use the database libraries' native APIs if you wish, but I think that would be foolish if your goal is really optimization and you haven't identified the components as the source of your program's non-optimal behavior. Consider how much time and effort it would take you to rewrite your program without the database components.
I don't see how a form-based dataset/query/table/etc., would be faster or slower than one created in code. However, I like to put them in code as it's easier to maintain. I've seen screens with SQL embedded in a component, and then it's overridden in the code. Then I have to stop and investigate to determine which SQL is actually in effect. Sometimes the SQL in the form is good, sometimes it's used for a while and then trumped by the code, sometimes it's never active and the SQL is trumped in the formcreate. So I have to determine whether this is by design, or just sloppy leftovers. Also, it's easy to miss SQL changes in code reviews if they're in the .DFM and not the .PAS. i.e. I don't always look at the .DFM because I'm not interested in whether a label caption changed or a button moved.
So while it's nice for prototyping, when it comes to production code, you're better off having all of your database logic (SQL, table and field definitions) in the .pas file.
Update: I have finally given CnPack a try. Among the dozens of goodies, is a brilliant tool called "convert selected components to code". Form Design Wizard | More... | Convert Selected Components To Code. It does it all for you.
This is not a matter of being a component or not a component. If it comes to database access then BDE is extremely slow so changing it for sth else is a good move.
By the way - optimization is not about 'proven techniques' - it's about identifying a problem and solving it. If the problem happens to be slow db access then this is what you have to change.
Generally no. There is no additional overhead in using a non-visual component. It is created very quickly and works at runtime exactly at the same speed as one "created in code".
I'm looking for recommendations for a spreadsheet-like input facility to sit in an ASP MVC environment.
The client currently has a large number of very complex interlinked shared spreadsheets (which they are effectively running 90% of their core business from) for collecting and processing information. They wish to move this to a web application and require ASP MVC. They realise that they will not be able to display as much information on screen as they do currently with their spreadsheets, so a 40 x 60 grid should suffice in most cases. Of this they'll be a limited number of cells for data entry that will immediately update other cells in the grid using various spreadsheet-like formula. The grid must be AJAX enabled.
The quality of the user-interface is of primary concern here. As inevitably there will be a certain amount of resistance to move to database/web (and this project is a pilot anyway) the system must be as slick as possible. Almost as important is ease of implementation - the final system will be quite large so the quicker it is possible to configure the grid the better.
Either Open Source or commercial would be fine. HTML/Javascript, Silverlight and Flex implementations can all be considered.
I initially asked a similar question a year ago (it's taken that long for the client to agree the project) but I'm sure options have changed since then and our environment is now better defined.
I think Grapecity Spread will fit the bill , it can be easily built with MVC pattern and now it also supports the Razor View Engine .There is already a blog which details how to use Grapecity Spread with MVC , you can go through this here
http://www.gcpowertools.info/2011/12/using-grapecity-spread-for-net-with-mvc.html
Microsoft Silverlight. It is almost certainly your best bet for a rich line of business application with web deployment. It will allow you to utilise a consistent code base across your back-end and front-end component.
Whilst a number of commercial datagrid packages exist (Telerik, etc), I'd suggest using the default Datagrid component that is available, and understanding fully the databinding and templating options available.
Check out YUI's datatable, maybe what you need
http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html
I have used it and its great, very developer friendly and supports pagination.
When asked for a multi-line editable grid, I've done it two ways.
Dropped a SL control onto the page. This was incredibly easy.
A lot of javascript. Double-clicking a row made a row editable with several textboxes to span the gap. I don't think is what you're looking for, though.
For something quick and easy have a look at JqGrid demos to see if it can do what you want
http://www.trirand.com/blog/jqgrid/jqgrid.html
JQuery is already in MVC and being javascript it will work without plugins for the browser. However it may not be powerful enough for what you want in which case you going to need to look at Silver light etc. Could the project not be approached in a more web friendly manor?