I'm looking for options for connecting to (primarily reading data) UNIX/AIX/Business Basic from Windows systems.
I program in C# mostly so would need a .NET solution.
Solutions or comments are welcome.
It depends upon which Business Basic compiler you are using. the most common is BBx, so I will answer your question based upon this particular compiler. BBx will run seamless on Windows or Unix platforms. You can interchange programs between them without recompiling them. BUT, you must have a compiler to make it run. Remember that BBx, ProvideX, Thorobred basic, etc are all M-code compilers, and not P-code compilers. Most people use the utility program that comes with BBx to interchange data between the BBx environment and a web site. Go find the BBx manuals that come with the compiler. You can also use an OPTIONAL ODBC driver. Call Basis International In New Mexico for the driver. Later versions of BBx can also read/write to SQL databases and other types of file systems. But, most BBx programmers will use the keyed file system that comes with it. You can also read/write to ascii files in BBx.
Please note: BBx and all other Business Basic compilers do NOT use flat ascii files. They can write flat ascii files, but, in my 30 years I have never seen anyone use them as a file structure. They are only used to import/export data to/from BBx. The keyed files have a SIT area, Keyed Area, and a Data area. You NEED to read these files in BBx. If you use C or some other language to alter the data in the file, you corrupt the Checksum and the file will become useless. And, you will have one very pissed off customer.
You might also consider getting a BBx compiler for your Windows environment to help you. Pretty cheap option if you don't have source code on BBx side. Remember this ISN'T Basic...it's Business Basic.
You should also find the data structures of the file system on the BBx side. It is very hard to work with the system without it. Some programs will have DBMS on-board, and you can just print out the record layouts to the hundreds of files on the system.
It all depends a lot on the format that is used to store your data. If the data is just flat files, you could use something like rcp or ftp. A number of .NET componentens, both commercial and open-source are available for this kind of access.
If not, you can look for ODBC drivers. There are some vendors that sell drivers for BBX, C-ISAM, D-ISAM, etc..
I agree with Mike, the easiest way would be to use an ODBC. you can find one on the basis web site www.basis.com (they are bbx creators).
If you want fast on the fly access to the data you would be better of writing your own back-end in bbx and have it talk to you C# program using sockets.
I have written an Internet banking app (ASP.NET) talking to a bbx host in this way.
If you need further help feel free to ask.
BBX does has a MS-Dos version. With this you can fully approach all the databases in MS-Dos. With a tool DOSbox you can emulate ms-dos for windows 7 8 and 10.
Within windows you have to assign a windows driveletter to the network and location of your Unix database.
Within BBX it's possible to mount this drive.
Related
Many thanks #Mirko for the reply and comment. So sorry if im not clear myself.
I'll try to make it alot more understandable.
First thing is, I want to create an application for a Data Entry Form on Windows (Windows Form Application .exe). This application required database
and for a database server im thinking about SQL (Need some advise here on the server).
After the Form-Design completed and linked to the database, i want it to be able accessing PDF/PNG and stamping also, For approval purpose. Thus i need some file transfer server for this and some new coding line for this function. (I need a lot of help here especially the coding line).
Please note i've also tried making a form-based application on VBA Excel and use it's sheets for the database. But im struggling on how to make an access for File transfering and stamping (Approval) protocol. Thus lead me to C# on Visual Studio, hoping this coding program could handle such file-embed system.
Edit: Nico, I am not sure this will make a great SO question. Sorry, I cannot provide this detailed feedback in comments as they do not allow enough text. You are asking for advice that is in my opinion too broad. Meaning you really have many considerations here and are in essence asking (I think) how do I build a document management and approval (workflow) application.
You may want to look into document management solutions (I am no expert on those), but many handle approval flows and meta-data on documents well.
I would recommend you carefully consider even your starting assumptions. In my opinion if you are building a green-field application now you should decide between WPF (instead of Windows Forms) and a Web Application (that is in the .NET space) and I would probably recommend ASP.NET Core Razor Pages. If more than one person will use this application I would lean towards the latter strongly as it is more easily accessed and updated.
I am not the best person to answer how to do the Stamping approval part, but you may want to consider either an existing document management solution (maybe DocuSign, etc. as an integration) as they may offer you the features you are looking for out of the box. If not take a look at PDF libraries in the .NET space (I personally used Aspose in the past, but they tend to be expensive).
If you are looking to track metadata about the documents to be uploaded/approved SQL server is often a good choice, but since you are quite literally seeming to aim for document management, more document-centric options maybe a good fit (MongoDB, Cosmos (Azure), DocumentDB (AWS), ...) as they allow you to store arbitrary meta-data.
I will soon begin the painful*(kidding)* process of migrating multiple, separate, Access Applications to "Real" applications*(notice the quotes, no flame wars please)*. Most likely this will be Web Apps as the usual reason is multiple users and deployability but I will take it case by case.
Some of these are traditional Access apps using Access as the back end and others are using SQL Server(a central one) as the back end.
What I am looking for is a combination of your experience doing this and what resources you used to help.
Websites, apps, standards, best practices, gotcha's, don't forget's, etcetera.
I am a 1 person C# shop with SQL Server back end so whether Web or not I will be looking that direction.
Also, is it overkill or unattainable to try and develop a Framework for this kind of thing? Would there just be TOO MANY variables to even try and walk this path? Anyone ever try this?
Some further info based on below questions. We currently have ~250 users and they are spread between 5 Locations.
What I meant by deployability is perhaps a little vague. I simply meant that we are a Non-Profit Organization and as such we do not have the best bandwidth available so deploying full apps, even through ClickOnce can be tricky when combinded with the highly fickle nature of my users*(I want that box purple, no green, no get rid of it altogether type stuff...)*.
My idea is to try and develop a "framework", of sorts, that will help to streamline the process of moving an Access App to a .Net App.
Now I fully understand that this "framework" may be nothing more than a set of steps and guidelines; like, Use ORM*(LINQ2SQL or SubSonic)*to generate DAL, Copy UI to corresponding UserControls, rewrite Business Logic.
I am just looking for your experience/expertise to help me streamline my streamlining process... ;)
Those apps which use an Access database to store tables and which need web access should first be upsized to SQL Server. There is a tool from the SQL Server group. SQL Server Migration Assistant for Access (SSMA Access)
Then consider moving to the web only that portion of the app that requires remote access. And leaving the rest of the app in Access. That could save a considerable amount of time.
Alternatively consider going to Terminal Server. That along with a VPN means just some software licensing costs and next to no work on your part.
That said what do you mean by "multiple users" and "deployability"? Possibly we can give you some suggestions there. Access is multi user out of the box. However if you have mission critical data or can't rekey the data in the event of a corruption or have more than 25-50 users on the LAN then you should be moving the data to SQL Server.
Now that it's public Access 2010 can deploy applications to the web. All kinds of very interesting stuff can be done. For more information check the Microsoft Access product group blog or my blog with the appropriate Access 2010 tags
Speaking from experience I think you would need to upgrade on a case by case basis. Upgrading is essentially a re-write from scratch and you should take the opportunity here to re-design as necessary. The type of application structure and code style used for Access (likely to be procedural I'm guessing) is very different to a well designed OO .Net app.
You will be able to re-use the SQL Server databases of course and, depending on the apps maybe even the Access ones. If you're feeling brave you could even try the upsizing wizard although I wouldn't recommend it as we found the results less than ideal.
I would also advise you take a look at some kind of ORM tool (we use Subsonic) as this can massively reduce the amount of boiler plate code you need to write. Some ORM tools will also generate DDL for your database too.
We follow these standards (good idea to pick a standard early on and stick to it we found) and also found this really useful to get up and running.
Hope this was some help.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am the lone .NET developer in an non-IT organization. I've been asked to develo ae .NET application using Microsoft Access as the back-end (existing DB).
I don't know where to start.
Since I'm developing by myself, what should I keep in mind to avoid during development? What situations does only a lone developer face?
Please include Microsoft Access specific advice in your answer, since that is germane to the question.
Where to start?
Choose a development environment (I would suggest Visual Studio 2008 Express or Professional, depending on the budget and the need for features of the Professional version)
Even for one single developer: choose a Version control system !!!! (Subversion has only little administrative overhead, fine for one developer)
Choose a .NET Framework version (3.5 is fine unless your application has to run on Win2K; for Win2K use .NET 2.0)
Choose a mature programming language (C# or VB.NET, what you or your boss likes best)
Choose a GUI technology (for a single developer, I would suggest using WinForms, unless you are going to write a Web application or a command line utility)
Choose a mature DB access technology (ADO.NET works for a lot of things, unless you have very high performance requirements that are better dealt with old ADO/OleDB or DAO)
EDIT: use Google to find some entry examples according to the choosen technology, or buy yourself a book. For example, here is one for C# using OLE DB to access a MS Access DB. This Access site is a good starting point, too.
EDIT2: make yourself familiar with "Microsoft Access" (the Office Application). Not because you are going to use it like a typical user, but you will probably need it for administrative purposes. And the VBA & SQL documentation included will be sometimes helpful, even if you code with C# or VB.NET
EDIT3: for reporting purposes, choose a reporting technology. There are plenty of possibilites here, depending on your needs, your skills and/or budget, for example
Plain ASCII or CSV reports (coded by hand)
HTML or XML reports
using Excel as reporting engine
using a PDF library like Report.NET
using a third party tool like Crystal Reports
You will find a lot of helpful links when you give "report generation .net" to Google, for example this one.
And finally: come back to SO and ask more concrete questions when you come to the point where you have them.
There might be other constraints, depending on what code is already existing in your organization. And I would avoid technologies like F#, WPF or Linq to Entities.
Your question is too vague to give more than just general advice. If you have already developed other .Net applications, then the approach to developing this new application should not really be any different.
Database considerations:
The only things to bear in mind when using MS Access as a back-end database are:
Scalability - MS Access does not
scale very well and is only suitable
for a small number of users
*EDIT: Numbers vary depending on the type of activity the users are performing - for a reporting solution, Microsoft themselves suggest that up to ~100 concurrent users is the maximum - this white paper provides more information *
Security - MS Access does not offer the same sophisticated levels
of security that you will find in
other database products (SQL Server,
Oracle, MySQL)
SQL Syntax - there are some subtle differences in the way you
write certain types of query for MS
Access
Other Limitations - MS Access does not support stored procedures, so all your data access code will have to use inline SQL Commands (command.Type = CommandType.Text)
The maximum database size supported by Microsoft Access is 2GB - keep an eye on the growth of the database
Design considerations:
Does the existing MS Access database already have some user forms and code modules in it? If so, you could use these as the basis for your application - MS Access uses Visual Basic for Applications (VBA) as it's programming language and there are no tools/utilities that I know of that will port VBA to VB.Net
Do similar applications exist elsewhere that could help inform your design?
Keep data access code out of your forms as much as possible - try to keep data access code in a separate class/DLL so that it is easier to maintain
EDIT: as others have suggested, try to avoid having instances of ADO.Net connection and command objects scattered throughout the user interface - put all database connection code in one class/DLL so that it easier to fix/maintain/replace. I'd also suggest putting all your SQL query statements in a separate class or module for the same reason. *
Follow any in-house guidelines that you, or others before you, have put in place.
Keep maintainability in mind - someone after you may have to make changes. Use comments in code and give your objects (forms/variables/function names) sensible names
Take regular backups of your code - put a copy on a network drive or USB drive every day
One point of advice, encapsulate all Access-specific code within a single class. The class should at least be able to:
locate the Access .mdb file
create and open all OleDbConnection objects
It's critical that all Connections are guaranteed to close, so wrapping their use in a using block is a very good idea
(Possibly) build and execute all OleDbCommands (removing the db-specific logic from the consuming components--they should be able to make data-requests and retrieve results while transparently creating the Connection & Command, etc.
For accessing the Access database, you could maybe have a look at NHibernate? As far as I know it supports Microsoft Access and using a library like that could perhaps make things easier if you are going to move the data to some other kind of database later on.
If you are already familiar with a .NET language and MS Access then my advice would be to start off by developing a very simple MS Access database and write a small .NET console application that connects to that database and performs some basic functions e.g. querying/inserting/deleting/updating. Then its just a case of builiding on top of this piece by peice, introducing GUIs/separate libs (dlls) etc on the way.
Unfortunately for you .NET Linq to SQL (ORM) does not support MS Access databases so you will have to develop your Business Objects from scratch (not always a bad thing!).
Here is a good starting point MS Application with C#.
There is a lot of good advice here, all I would add is be sure to build all your data access and modifying classes behind a well defined interface(s). I am sure there will come a time when this application out grows MS Access and having well defined interfaces will make upgrading to another database easier.
I'm developing what is essentially a specialized firewall application. The solution needs to be 32 and 64-bit compatible. My company wants to keep the current program interface, which is written in C#.
What I need is this: a way to monitor and manipulate all network traffic on the system. My research has led me to believe that a NDIS (Network Driver Interface Specification) Intermediate driver is the way to go. If I can write this kind of driver in C#, great, but I'm not sure that's possible. At the very least, I need an interface in C# to a driver written in any language.
I found a great resource online for creating one in a series of articles entitled "Extending the Microsoft PassThru NDIS Intermediate Driver":
Part 1 - Adding a DeviceIoControl Interface
Part 2 - Two IP Address Blocking NDIS IM Drivers
Part 3 - Supporting Windows XP 64-Bit Edition
However, it is dated (2003). Before I invest in reading and learning what it has to say, I want to make sure I'm not wasting my time.
Is there a better way to do this? Are there any open source projects or articles that explain the process better than the articles above? Am I even in the ballpark? Help please.
There's another page from the same author, titled Windows Network Data and Packet Filtering, which provides "a brief introduction to various techniques that can be used to filter network data and network packets on the Microsoft Windows platforms".
It mentions others options, e.g. "TDI flter driver" and "User-Mode Network Data Filtering", which may suit instead, depending on whether you really want to manipulate all the network traffic on the system.
We have some very large data files (5 gig to 1TB) where we need quick read/write access. Since we have a fixed record size it seems like some form of ISAM would be the way to go. But would be happy to hear other suggestions.
Ideally the solution would have an Apache or LGPL style license but we will pay if we have to.
Must haves:
Scalable - over at least 1 TB files
Stable - either doesn't corrupt data or has fast recovery process
Runs well on X64 Windows
Nice to have:
Can participate in 2 phase commits
Intrinsic compression facilities
Portable to *nix platforms
C# API or Java API
Thanks,
Terence
You can also use the ESENT database engine which is built into Windows. As far as your requirements go:
Scalable: the maximum database size
is 16TB. Multi-TB datbases have been
used in production.
Stable: crash recovery with
write-ahead logging.
X64 Windows: ESENT is part of
Windows, so it is present on your
64-bit machine.
Nice to have:
2 phase commits: No.
Compression: No.
Portable to *nix: No.
C# API or Java API: Not really (there is a C# interop layer on Codeplex but it isn't complete).
The documentation is here: http://msdn.microsoft.com/en-us/library/ms684493(VS.85).aspx
You can get the header file and lib by downloading the Windows SDK.
Give Berkeley DB a try. Opinions vary, but it's scalable, stable (if you use all necessary layers) and AFAIK runs well on x64 windows. Also portable to *nix and has C and Java API. Don't know about C# API.